perm filename MSG.MSG[X3,LSP]36 blob
sn#868563 filedate 1989-01-12 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00406 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00054 00002 ∂09-Oct-86 0616 jjohnson@mitre.ARPA ANSI X3J13 committee
C00056 00003 ∂09-Oct-86 1136 RPG Greetings
C00057 00004 ∂10-Oct-86 1547 @REAGAN.AI.MIT.EDU:Hewitt@XX.LCS.MIT.EDU Meeting conflict
C00059 00005 ∂27-Oct-86 0653 MATHIS@ADA20.ISI.EDU X3J13 Meeting Dallas Dec 10-12
C00066 00006 ∂05-Nov-86 0723 MATHIS@ADA20.ISI.EDU x3j13 second mailing
C00068 00007 ∂14-Nov-86 1137 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Delta reference number
C00070 00008 ∂14-Nov-86 1136 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET December Meeting
C00072 00009 ∂25-Nov-86 1302 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Reservation confirmation
C00075 00010 ∂27-Nov-86 1355 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Additional reservations
C00077 00011 ∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU meeting in Dallas
C00078 00012 ∂05-Dec-86 1734 MATHIS@ADA20.ISI.EDU Dallas meeting draft agenda outline
C00081 00013 ∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU third mailing cover letter
C00088 00014 ∂05-Dec-86 1825 FAHLMAN@C.CS.CMU.EDU Logisitcs for Dallas meeting
C00090 00015 ∂08-Dec-86 0902 jjohnson@mitre.ARPA Re: meeting in Dallas
C00091 00016 ∂10-Dec-86 0358 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Logistics for Dallas Meeting
C00093 00017 ∂12-Dec-86 1900 MATHIS@ADA20.ISI.EDU Dallas meeting
C00094 00018 ∂15-Dec-86 1630 RPG Contents of the X3J13 mailing list
C00098 00019 ∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU minutes of Dallas meeting
C00100 00020 ∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU proposed purposes
C00107 00021 ∂19-Dec-86 0727 FAHLMAN@C.CS.CMU.EDU proposed purposes
C00109 00022 ∂19-Dec-86 0831 Bobrow.pa@Xerox.COM Re: proposed purposes
C00111 00023 ∂19-Dec-86 0936 ohlander@venera.isi.edu Re: proposed purposes
C00113 00024 ∂19-Dec-86 0958 ohlander@venera.isi.edu Re: proposed purposes
C00115 00025 ∂19-Dec-86 1155 berman@vaxa.isi.edu Re: proposed purposes,
C00117 00026 ∂19-Dec-86 1323 DLW@ALDERAAN.SCRC.Symbolics.COM proposed purposes
C00119 00027 ∂19-Dec-86 2017 Moon@RIVERSIDE.SCRC.Symbolics.COM proposed purposes
C00122 00028 ∂22-Dec-86 1849 hpfclp!dcm@hplabs.HP.COM Charter statement
C00128 00029 ∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU 2nd meeting minutes X3J13/86-021
C00147 00030 ∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU proposed purposes X3J13/86-020
C00152 00031 ∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU general letter X3J13/86-022
C00158 00032 ∂06-Jan-87 0723 MATHIS@ADA20.ISI.EDU task groups
C00164 00033 ∂06-Jan-87 2157 edsel!bhopal!jonl@navajo.stanford.edu proposed purposes
C00168 00034 ∂15-Jan-87 1329 Mailer@XX.LCS.MIT.EDU Document 86-019
C00195 00035 ∂15-Jan-87 2015 Moon@STONY-BROOK.SCRC.Symbolics.COM Document 86-019
C00202 00036 ∂16-Jan-87 0822 FAHLMAN@C.CS.CMU.EDU Document 86-019
C00205 00037 ∂16-Jan-87 1124 Masinter.pa@Xerox.COM Re: Document 86-019, &function, etc.
C00207 00038 ∂16-Jan-87 2155 willc%tekchips.tek.com@RELAY.CS.NET Re: Document 86-019
C00215 00039 ∂22-Jan-87 1732 RPG March X3J13 Meeting in Palo Alto
C00226 00040 ∂10-Feb-87 0246 RPG Registration
C00227 00041 ∂10-Feb-87 2209 RPG Reminder About March Registration Procedure
C00238 00042 ∂13-Feb-87 1948 MATHIS@ADA20.ISI.EDU plans for Palo Alto and mailing
C00245 00043 ∂27-Feb-87 1453 RPG X3 registration list 2/27/87
C00250 00044 ∂27-Feb-87 1513 ohlander@venera.isi.edu Re: X3 registration list 2/27/87
C00252 00045 ∂03-Mar-87 1251 berman@vaxa.isi.edu Re: Who's Where?
C00254 00046 ∂03-Mar-87 1359 berman@vaxa.isi.edu Validation
C00258 00047 ∂07-Mar-87 1414 MATHIS@ADA20.ISI.EDU agenda update
C00260 00048 ∂12-Mar-87 2210 RPG Final Attendee List
C00267 00049 ∂13-Mar-87 0204 brown%bizet.DEC@decwrl.DEC.COM Technical Editor
C00269 00050 ∂13-Mar-87 0852 RPG Writer
C00270 00051 ∂18-Mar-87 1341 MATHIS@ADA20.ISI.EDU draft minutes Palo Alto meeting
C00285 00052 ∂18-Mar-87 1342 MATHIS@ADA20.ISI.EDU meeting documents
C00306 00053 ∂20-Mar-87 1345 primerd!doug@enx.prime.pdn Windows and Graphics Subcommittee
C00308 00054 ∂23-Mar-87 1130 berman@vaxa.isi.edu Gary Brown...
C00309 00055 ∂20-Apr-87 0042 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the Kanji feature of Common Lisp
C00313 00056 ∂20-Apr-87 2253 dcm%hpfclp@hplabs.HP.COM Fall X3J13 meeting
C00317 00057 ∂21-Apr-87 0821 RWK@YUKON.SCRC.Symbolics.COM On the Kanji feature of Common Lisp
C00320 00058 ∂23-Apr-87 0106 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the character-set extension of Common Lisp
C00324 00059 ∂15-May-87 0436 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Next Meeting
C00326 00060 ∂31-May-87 0903 MATHIS@ADA20.ISI.EDU
C00332 00061 ∂31-May-87 0915 MATHIS@ADA20.ISI.EDU A multi-byte character extension proposal
C00374 00062 ∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 1 of 2
C00424 00063 ∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 2 of 2
C00480 00064 ∂01-Jun-87 0532 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol script
C00487 00065 ∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 3 of 6
C00533 00066 ∂01-Jun-87 0530 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 5 of 6
C00582 00067 ∂01-Jun-87 0527 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 1 of 6
C00632 00068 ∂01-Jun-87 0529 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 4 of 6
C00684 00069 ∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 2 of 6
C00739 00070 ∂01-Jun-87 0531 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 6 of 6
C00792 00071 ∂11-Jun-87 1121 Masinter.pa@Xerox.COM Issues from the cleanup committee
C00794 00072 ∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue DEFVAR-INIT-TIME (Version 2)
C00799 00073 ∂11-Jun-87 1619 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 11)
C00805 00074 ∂11-Jun-87 1620 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 6)
C00810 00075 ∂11-Jun-87 1622 Masinter.pa@Xerox.COM Issue FORMAT-OP-C (Version 5)
C00817 00076 ∂11-Jun-87 1620 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Version 4)
C00822 00077 ∂11-Jun-87 1619 Masinter.pa@Xerox.COM AREF-1D (Version 5)
C00828 00078 ∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue FORMAT-ATSIGN-COLON (Version 3)
C00832 00079 ∂11-Jun-87 1619 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 11)
C00838 00080 ∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: IMPORT-SETF-SYMBOL-PACKAGE (Version 5)
C00842 00081 ∂11-Jun-87 1625 Masinter.pa@Xerox.COM (REVISION) Issue: PATHNAME-STREAM (Version 3)
C00847 00082 ∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 2)
C00851 00083 ∂11-Jun-87 1622 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 4)
C00857 00084 ∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 6)
C00865 00085 ∂11-Jun-87 1842 Masinter.pa@Xerox.COM Issue: PRINC-CHARACTER (Version 2)
C00872 00086 ∂15-Jun-87 1920 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
C00884 00087 ∂16-Jun-87 2337 Masinter.pa@Xerox.COM
C00896 00088 ∂16-Jun-87 2336 Masinter.pa@Xerox.COM Issue: IF-BODY (Version 7)
C00910 00089 ∂16-Jun-87 2336 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (Version 5)
C00934 00090 ∂17-Jun-87 0844 barmar@AQUINAS.THINK.COM Issue: FUNCTION-TYPE (Version 5)
C00938 00091 ∂17-Jun-87 1150 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
C00945 00092 ∂17-Jun-87 1247 barmar@Think.COM Issue: FUNCTION-TYPE (Version 5)
C00951 00093 ∂17-Jun-87 1312 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
C00954 00094 ∂17-Jun-87 1535 DLW@ALDERAAN.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
C00958 00095 ∂17-Jun-87 1740 Mike%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU updcoming meeting
C00962 00096 ∂17-Jun-87 2011 FAHLMAN@C.CS.CMU.EDU Issue: IF-BODY (Version 7)
C00970 00097 ∂18-Jun-87 0736 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
C00973 00098 ∂18-Jun-87 0821 shebs%orion@cs.utah.edu IF with multiple ELSE
C00975 00099 ∂18-Jun-87 0913 barmar@AQUINAS.THINK.COM Issue: IF-BODY (Version 7)
C00980 00100 ∂18-Jun-87 1001 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
C00983 00101 ∂18-Jun-87 1740 RWK@YUKON.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
C00987 00102 ∂18-Jun-87 2350 RWK@YUKON.SCRC.Symbolics.COM IF with multiple ELSE
C00991 00103 ∂19-Jun-87 2100 edsel!bhopal!jonl@navajo.stanford.edu IF with multiple ELSE
C00995 00104 ∂19-Jun-87 2204 Moon@STONY-BROOK.SCRC.Symbolics.COM IF with multiple ELSE
C00997 00105 ∂20-Jun-87 0437 edsel!bhopal!jonl@navajo.stanford.edu IF with multiple ELSE
C00999 00106 ∂21-Jun-87 1652 franz!frisky!jkf@ucbarpa.Berkeley.EDU Re: IF with multiple ELSE
C01001 00107 ∂22-Jun-87 0935 DLW@ALDERAAN.SCRC.Symbolics.COM Re: IF with multiple ELSE
C01003 00108 ∂22-Jun-87 1013 cperdue@Sun.COM Re: IF with multiple ELSE
C01006 00109 ∂22-Jun-87 1112 DLW@ALDERAAN.SCRC.Symbolics.COM Re: IF with multiple ELSE
C01008 00110 ∂22-Jun-87 1126 FAHLMAN@C.CS.CMU.EDU IF with multiple ELSE
C01011 00111 ∂22-Jun-87 1207 barmar@Think.COM Re: IF with multiple ELSE
C01015 00112 ∂22-Jun-87 1214 shebs@cs.utah.edu Purpose of this Mailing List
C01017 00113 ∂23-Jun-87 1104 RPG Meeting Room at MIT
C01020 00114 ∂25-Jun-87 2342 RPG Meeting Room
C01021 00115 ∂26-Jun-87 1048 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Meeting Room
C01023 00116 ∂30-Jun-87 1109 procyon@Cs.Ucl.AC.UK Common Lisp Mailing List
C01024 00117 ∂02-Jul-87 1648 MATHIS@ADA20.ISI.EDU BALLOT! ISO NWI
C01026 00118 ∂05-Jul-87 1803 MATHIS@ADA20.ISI.EDU DRAFT letter and ballot
C01053 00119 ∂12-Jul-87 2020 MATHIS@ADA20.ISI.EDU x3j13 ballot
C01078 00120 ∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu "Iteration" activity
C01083 00121 ∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu LOOP "Blurb & Crib Sheet"
C01108 00122 ∂22-Jul-87 0741 FAHLMAN@C.CS.CMU.EDU Iteration proposals
C01110 00123 ∂23-Jul-87 0944 edsel!bhopal!jonl@labrea.stanford.edu Iteration proposals
C01113 00124 ∂14-Aug-87 0803 @HAL.CAD.MCC.COM:Loeffler@MCC.COM Windows Subcommittee
C01115 00125 ∂15-Sep-87 0424 MATHIS@ADA20.ISI.EDU report on ISO NWI and SC22 meeting
C01121 00126 ∂15-Sep-87 0929 dcm%hpfclp@hplabs.HP.COM October X3J13 meeting
C01136 00127 ∂16-Sep-87 1145 dcm%hpfclp@hplabs.HP.COM November X3J13 meeting
C01150 00128 ∂24-Sep-87 0312 @RELAY.CS.NET:yuasa%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Japanese Activities toward Lisp Standardization
C01158 00129 ∂20-Oct-87 1636 @RELAY.CS.NET:DUSSUD@jenner.csc.ti.com Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP 20 Oct 87 16:36:09 PDT
C01161 00130 ∂22-Oct-87 0839 ROSENKING@A.ISI.EDU Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP 22 Oct 87 08:39:11 PDT
C01163 00131 ∂26-Oct-87 0522 MATHIS@C.ISI.EDU next meeting
C01166 00132 ∂26-Oct-87 1233 MATHIS@C.ISI.EDU Wednesday afternoon agenda
C01168 00133 ∂29-Oct-87 1212 X3J13-mailer November X3J13 meeting
C01185 00134 ∂11-Nov-87 1800 X3J13-mailer Final reservations
C01191 00135 ∂12-Nov-87 1335 X3J13-mailer next meeting
C01194 00136 ∂29-Nov-87 1424 X3J13-mailer subcommittees
C01198 00137 ∂02-Dec-87 1545 X3J13-mailer 11-87 minutes
C01210 00138 ∂14-Dec-87 1055 X3J13-mailer March meeting
C01222 00139 ∂11-Jan-88 1056 X3J13-mailer mailings
C01224 00140 ∂11-Jan-88 1249 X3J13-mailer mailings
C01230 00141 ∂26-Jan-88 1107 X3J13-mailer voting
C01235 00142 ∂01-Feb-88 1511 X3J13-mailer Don't forget mailings
C01237 00143 ∂13-Feb-88 1728 X3J13-mailer Issues from the cleanup sub-committee
C01241 00144 ∂14-Feb-88 1045 X3J13-mailer Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
C01249 00145 ∂14-Feb-88 1049 X3J13-mailer Issue: APPEND-DOTTED (Version 5)
C01257 00146 ∂14-Feb-88 1057 X3J13-mailer Issue: AREF-1D (Version 7)
C01264 00147 ∂14-Feb-88 1103 X3J13-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
C01269 00148 ∂14-Feb-88 1109 X3J13-mailer Issue: COLON-NUMBER (Version 1)
C01274 00149 ∂14-Feb-88 1112 X3J13-mailer Issue COMPILER-WARNING-BREAK (Version 4)
C01279 00150 ∂14-Feb-88 1125 X3J13-mailer Issue: DEFVAR-DOCUMENTATION (Version 2)
C01284 00151 ∂14-Feb-88 1130 X3J13-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
C01289 00152 ∂14-Feb-88 1122 X3J13-mailer Issue: DECLARE-MACROS (Version 3)
C01304 00153 ∂14-Feb-88 1137 X3J13-mailer Issue: DO-SYMBOLS-DUPLICATES (Version 3)
C01310 00154 ∂14-Feb-88 1155 X3J13-mailer Issue: DRIBBLE-TECHNIQUE (Version 2)
C01316 00155 ∂14-Feb-88 1201 X3J13-mailer Issue: FLET-DECLARATIONS (Version 2)
C01322 00156 ∂14-Feb-88 1204 X3J13-mailer Issue: FORMAT-COMMA-INTERVAL (Version 2)
C01328 00157 ∂14-Feb-88 1214 X3J13-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
C01337 00158 ∂14-Feb-88 1223 X3J13-mailer Issue FUNCTION-TYPE-KEY-NAME, Version 3
C01344 00159 ∂14-Feb-88 1231 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
C01353 00160 ∂14-Feb-88 1301 X3J13-mailer Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
C01361 00161 ∂14-Feb-88 1310 X3J13-mailer Issue: PATHNAME-STREAM (Version 6)
C01368 00162 ∂14-Feb-88 1306 X3J13-mailer Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
C01382 00163 ∂14-Feb-88 1300 X3J13-mailer Issue: FUNCTION-TYPE (version 9)
C01411 00164 ∂14-Feb-88 1328 X3J13-mailer Issue: PATHNAME-SYMBOL (Version 5)
C01420 00165 ∂14-Feb-88 1338 X3J13-mailer Issue: PUSH-EVALUATION-ORDER (Version 5)
C01435 00166 ∂14-Feb-88 1352 X3J13-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
C01441 00167 ∂14-Feb-88 1341 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
C01461 00168 ∂14-Feb-88 1354 X3J13-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
C01474 00169 ∂14-Feb-88 1408 X3J13-mailer
C01481 00170 ∂14-Feb-88 1406 X3J13-mailer Issue: SHADOW-ALREADY-PRESENT (version 4)
C01490 00171 ∂14-Feb-88 1455 X3J13-mailer Common Lisp cleanup issue status to X3J13
C01510 00172 ∂16-Feb-88 1045 X3J13-mailer March 1988 agenda questions
C01512 00173 ∂16-Feb-88 2122 X3J13-mailer March 1988 agenda questions
C01514 00174 ∂23-Feb-88 1308 X3J13-mailer Re: voting
C01516 00175 ∂23-Feb-88 1541 X3J13-mailer voting
C01528 00176 ∂24-Feb-88 1139 X3J13-mailer X3J13 committee meeting agenda draft
C01531 00177 ∂24-Feb-88 1139 X3J13-mailer Subcommittee meetings
C01534 00178 ∂24-Feb-88 1140 X3J13-mailer voting at X3J13
C01537 00179 ∂28-Feb-88 1147 X3J13-mailer ISO meeting news
C01539 00180 ∂01-Mar-88 1445 X3J13-mailer X3 attendee list to date
C01543 00181 ∂02-Mar-88 1203 Common-Lisp-mailer Request to be added to mailing list...
C01545 00182 ∂02-Mar-88 1350 X3J13-mailer Re: X3 attendee list to date
C01547 00183 ∂04-Mar-88 1440 X3J13-mailer X3J13 attendee list
C01553 00184 ∂07-Mar-88 1542 X3J13-mailer new and improved list
C01559 00185 ∂08-Mar-88 1121 X3J13-mailer Re: X3J13 attendee list
C01561 00186 ∂08-Mar-88 1339 X3J13-mailer X3 attendee list to date
C01563 00187 ∂19-Mar-88 1821 X3J13-mailer last meeting
C01565 00188 ∂19-Mar-88 1844 X3J13-mailer minutes 3/88 mtg
C01585 00189 ∂21-Apr-88 0708 X3J13-mailer X3J13 Meeting 6/13 - 6/17/88
C01587 00190 ∂21-Apr-88 0829 X3J13-mailer X3J13 Meeting
C01595 00191 ∂21-Apr-88 0908 X3J13-mailer X3J13 Meeting
C01603 00192 ∂21-Apr-88 1242 X3J13-mailer X3J13 Meeting
C01606 00193 ∂21-Apr-88 1306 X3J13-mailer X3J13 Meeting
C01609 00194 ∂21-Apr-88 1352 X3J13-mailer X3J13 Meeting
C01612 00195 ∂22-Apr-88 0114 X3J13-mailer X3J13 Meeting
C01615 00196 ∂25-Apr-88 1415 X3J13-mailer June Meeting addendum and varia
C01619 00197 ∂25-Apr-88 1830 X3J13-mailer June Meeting addendum and varia
C01621 00198 ∂25-Apr-88 1937 X3J13-mailer X3J13 Meeting
C01623 00199 ∂26-Apr-88 0848 X3J13-mailer June Meeting addendum and varia
C01625 00200 ∂27-Apr-88 0100 X3J13-mailer June Meeting addendum and varia
C01627 00201 ∂27-Apr-88 0104 X3J13-mailer June Meeting addendum and varia
C01629 00202 ∂28-Apr-88 1315 X3J13-mailer mail to bouzane for June X3 meeting
C01631 00203 ∂10-May-88 1438 X3J13-mailer X3J13 June Meeting
C01635 00204 ∂10-May-88 2005 X3J13-mailer Re: June Meeting
C01637 00205 ∂16-May-88 1119 X3J13-mailer agenda items please
C01639 00206 ∂19-May-88 1621 X3J13-mailer mailing deadline approaches
C01641 00207 ∂23-May-88 1640 X3J13-mailer June agenda draft
C01644 00208 ∂30-May-88 1838 X3J13-mailer mailing list and next meeting
C01649 00209 ∂02-Jun-88 1614 X3J13-mailer 88-007
C01651 00210 ∂07-Jun-88 1559 X3J13-mailer Issue: FUNCTION-TYPE (version 11)
C01671 00211 ∂08-Jun-88 1211 X3J13-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
C01677 00212 ∂08-Jun-88 1237 X3J13-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 1)
C01682 00213 ∂08-Jun-88 1244 X3J13-mailer Issue: DECLARATION-SCOPE (Version 2)
C01697 00214 ∂08-Jun-88 1509 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
C01701 00215 ∂08-Jun-88 1524 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER (Version 1)
C01705 00216 ∂08-Jun-88 1531 X3J13-mailer Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
C01714 00217 ∂08-Jun-88 1806 X3J13-mailer Issue: EVAL-OTHER (Version 2)
C01721 00218 ∂08-Jun-88 1752 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 2)
C01733 00219 ∂08-Jun-88 1918 X3J13-mailer Issue: DEFPACKAGE (version 2)
C01745 00220 ∂08-Jun-88 1946 X3J13-mailer Issue: FUNCTION-CALL-EVALUATION-ORDER (Version 1)
C01749 00221 ∂08-Jun-88 1958 X3J13-mailer Issue: LAST-N (Version 2)
C01754 00222 ∂08-Jun-88 2030 X3J13-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION
C01762 00223 ∂08-Jun-88 2049 X3J13-mailer Issue: MACRO-FUNCTION-ENVIRONMENT
C01768 00224 ∂08-Jun-88 2058 X3J13-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
C01775 00225 ∂08-Jun-88 2103 X3J13-mailer Issue SUBSEQ-OUT-OF-BOUNDS, version 2
C01782 00226 ∂09-Jun-88 0714 CL-Cleanup-mailer Issue: LAST-N (Version 2)
C01784 00227 ∂09-Jun-88 0907 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
C01786 00228 ∂09-Jun-88 1043 X3J13-mailer [bouzane@scrc-pegasus: X3J13 Meeting]
C01789 00229 ∂09-Jun-88 1525 X3J13-mailer Issue: DECLARATION-SCOPE (Version 2)
C01791 00230 ∂09-Jun-88 2119 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 2)
C01798 00231 ∂09-Jun-88 2136 X3J13-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION
C01802 00232 ∂09-Jun-88 2307 X3J13-mailer Issue status
C01805 00233 ∂10-Jun-88 0056 X3J13-mailer Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 4)
C01815 00234 ∂10-Jun-88 0107 X3J13-mailer Issue: SPECIAL-VARIABLE-TEST (Version 2)
C01823 00235 ∂10-Jun-88 0108 X3J13-mailer Issue: STEP-ENVIRONMENT (Version 1)
C01829 00236 ∂10-Jun-88 0154 X3J13-mailer Issues for discussion at June 1988 X3J13 meeting
C01835 00237 ∂07-Jul-88 0732 X3J13-mailer DRAFT Minutes June meeting
C01860 00238 ∂11-Aug-88 1444 X3J13-mailer CLOS workshop
C01865 00239 ∂11-Aug-88 1607 X3J13-mailer CLOS workshop
C01870 00240 ∂19-Aug-88 1210 X3J13-mailer Virginia and Hawaii X3J13 meetings
C01879 00241 ∂04-Sep-88 1352 X3J13-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 2)
C01884 00242 ∂04-Sep-88 1342 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
C01904 00243 ∂08-Sep-88 1751 X3J13-mailer Fairfax X3 registration form
C01910 00244 ∂12-Sep-88 0841 X3J13-mailer Availability of the standard
C01912 00245 ∂12-Sep-88 1344 X3J13-mailer Common Lisp Mailing Lists
C01913 00246 ∂12-Sep-88 1954 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
C01921 00247 ∂13-Sep-88 0841 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
C01927 00248 ∂13-Sep-88 1139 X3J13-mailer Re: Issue: FUNCTION-TYPE (version 12)
C01930 00249 ∂15-Sep-88 0225 X3J13-mailer "passed" cleanup issues
C01934 00250 ∂15-Sep-88 1617 X3J13-mailer additional passed clean-up issues
C01936 00251 ∂16-Sep-88 1145 X3J13-mailer agenda items please
C01939 00252 ∂16-Sep-88 1157 X3J13-mailer subcommittee meetings
C01941 00253 ∂19-Sep-88 1857 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
C01944 00254 ∂23-Sep-88 1056 X3J13-mailer issue COMPILE-FILE-PACKAGE
C01947 00255 ∂23-Sep-88 1053 X3J13-mailer compiler cleanup issue status
C01952 00256 ∂23-Sep-88 1056 X3J13-mailer issue OPTIMIZE-DEBUG-INFO
C01957 00257 ∂23-Sep-88 1057 X3J13-mailer issue PROCLAIM-INLINE-WHERE
C01962 00258 ∂23-Sep-88 1055 X3J13-mailer issue COMPILE-ARGUMENT-PROBLEMS
C01968 00259 ∂23-Sep-88 1054 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL
C01982 00260 ∂23-Sep-88 1058 X3J13-mailer **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY
C01996 00261 ∂23-Sep-88 1054 X3J13-mailer issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
C02010 00262 ∂23-Sep-88 1058 X3J13-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE
C02020 00263 ∂23-Sep-88 1055 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL
C02031 00264 ∂23-Sep-88 1212 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL
C02034 00265 ∂26-Sep-88 0931 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL
C02041 00266 ∂26-Sep-88 0931 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)
C02047 00267 ∂26-Sep-88 0931 X3J13-mailer issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
C02062 00268 ∂26-Sep-88 1041 X3J13-mailer Re: issue EVAL-WHEN-NON-TOP-LEVEL
C02065 00269 ∂26-Sep-88 1203 X3J13-mailer Hawaii hotel arrangements
C02067 00270 ∂29-Sep-88 1544 X3J13-mailer Fairfax attendees
C02072 00271 ∂29-Sep-88 1546 X3J13-mailer Fairfax Subcommittee Meetings Update
C02074 00272 ∂29-Sep-88 1544 X3J13-mailer Fairfax Updated Agenda DRAFT
C02077 00273 ∂29-Sep-88 1825 X3J13-mailer Re: Fairfax Updated Agenda DRAFT
C02079 00274 ∂30-Sep-88 0956 X3J13-mailer Fairfax attendees
C02081 00275 ∂30-Sep-88 1236 X3J13-mailer March '89 X3J13/ISO meeting host needed
C02083 00276 ∂30-Sep-88 1405 X3J13-mailer Arpanet access during Fairfax meeting
C02085 00277 ∂03-Oct-88 1122 X3J13-mailer Subcommittee Meetings at Contel
C02087 00278 ∂03-Oct-88 1252 X3J13-mailer Error terminology
C02109 00279 ∂04-Oct-88 1159 X3J13-mailer Hotel reservations for Hawaii
C02111 00280 ∂04-Oct-88 2041 X3J13-mailer Re: error definitions
C02115 00281 ∂06-Oct-88 1249 X3J13-mailer Issue: ERROR-NOT-HANDLED (Version 1)
C02121 00282 ∂06-Oct-88 1317 X3J13-mailer Fairfax Registration
C02127 00283 ∂06-Oct-88 1328 X3J13-mailer Revised DRAFT Agenda
C02130 00284 ∂06-Oct-88 1714 X3J13-mailer X3J13 issues to be emailed: stay tuned for barrage
C02132 00285 ∂06-Oct-88 1718 X3J13-mailer Issue: ALIST-NIL (Version 4)
C02140 00286 ∂06-Oct-88 1752 X3J13-mailer Arpanet access during Dallas PI meeting
C02142 00287 ∂06-Oct-88 1806 X3J13-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)
C02148 00288 ∂06-Oct-88 1921 X3J13-mailer Issue: CONTAGION-ON-NUMERICAL-COMPARISONS (version 1)
C02155 00289 ∂06-Oct-88 2007 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 6)
C02165 00290 ∂06-Oct-88 2058 X3J13-mailer Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
C02171 00291 ∂06-Oct-88 2057 X3J13-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
C02178 00292 ∂06-Oct-88 2058 X3J13-mailer Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)
C02184 00293 ∂06-Oct-88 2058 X3J13-mailer Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, version 2
C02190 00294 ∂06-Oct-88 2058 X3J13-mailer Issue: EXPT-RATIO (Version 2)
C02196 00295 ∂06-Oct-88 2111 X3J13-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
C02204 00296 ∂06-Oct-88 2123 X3J13-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
C02210 00297 ∂06-Oct-88 2150 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)
C02220 00298 ∂07-Oct-88 0743 CL-Cleanup-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
C02222 00299 ∂07-Oct-88 1501 X3J13-mailer Issue HASH-TABLE-TESTS (Version 1)
C02230 00300 ∂07-Oct-88 1501 X3J13-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 2)
C02236 00301 ∂07-Oct-88 1643 X3J13-mailer Issue: NTH-VALUE (Version 3)
C02242 00302 ∂07-Oct-88 1642 X3J13-mailer Issue: LAMBDA-FORM (Version 3)
C02250 00303 ∂07-Oct-88 2151 X3J13-mailer Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
C02258 00304 ∂07-Oct-88 2151 X3J13-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
C02263 00305 ∂07-Oct-88 2150 X3J13-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
C02271 00306 ∂07-Oct-88 2152 X3J13-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
C02283 00307 ∂07-Oct-88 2206 X3J13-mailer STEP-ENVIRONMENT, version 3
C02288 00308 ∂07-Oct-88 2151 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
C02308 00309 ∂07-Oct-88 2215 X3J13-mailer Issue: STREAM-ACCESS (version 1)
C02317 00310 ∂07-Oct-88 2317 X3J13-mailer Issue: SUBTYPEP-TOO-VAGUE (Version 4)
C02325 00311 ∂07-Oct-88 2334 X3J13-mailer Issue: TAGBODY-CONTENTS (Version 4)
C02333 00312 ∂07-Oct-88 2343 X3J13-mailer Issue: VARIABLE-LIST-ASYMMETRY (Version 2)
C02338 00313 ∂08-Oct-88 1150 CL-Cleanup-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
C02341 00314 ∂08-Oct-88 1229 X3J13-mailer REPLY-TO: CL-CLEANUP@Sail.Stanford.Edu
C02343 00315 ∂08-Oct-88 1253 X3J13-mailer DRAFT Issue: CLOSED-STREAM-OPERATIONS (Version 2)
C02349 00316 ∂08-Oct-88 1320 X3J13-mailer DRAFT Issue: COERCE-INCOMPLETE (Version 1)+
C02363 00317 ∂08-Oct-88 1329 X3J13-mailer DRAFT Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)
C02384 00318 ∂08-Oct-88 1441 X3J13-mailer DRAFT Issue: DEFPACKAGE (version 6)
C02400 00319 ∂08-Oct-88 1547 X3J13-mailer DRAFT Issue: DEFSTRUCT-REDEFINITION (Version 1)
C02407 00320 ∂08-Oct-88 1605 X3J13-mailer Issue: DESCRIBE-INTERACTIVE (Version 2)
C02413 00321 ∂08-Oct-88 1651 X3J13-mailer DRAFT Issue: DOTTED-MACRO-FORMS (Version 2)
C02420 00322 ∂08-Oct-88 1651 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 5)
C02429 00323 ∂08-Oct-88 1651 X3J13-mailer Issue: EXIT-EXTENT (Version 3)
C02444 00324 ∂08-Oct-88 1703 X3J13-mailer DRAFT Issue: FORMAT-PRETTY-PRINT (version 5)
C02454 00325 ∂08-Oct-88 1726 X3J13-mailer DRAFT Issue: FUNCTION-COMPOSITION (Version 2)
C02464 00326 ∂08-Oct-88 1726 X3J13-mailer DRAFT Issue: FUNCTION-COERCE-TIME (Version 2)
C02477 00327 ∂08-Oct-88 1741 X3J13-mailer DRAFTIssue: HASH-TABLE-ACCESS (version 1)
C02483 00328 ∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
C02494 00329 ∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
C02510 00330 ∂08-Oct-88 1751 X3J13-mailer DRAFT Issue: HASH-TABLE-PRINTED-PREPRESENTATION (Version 2)
C02520 00331 ∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: FUNCTION-DEFINITION (Version 1)
C02540 00332 ∂08-Oct-88 1956 X3J13-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 3)
C02548 00333 ∂08-Oct-88 2035 X3J13-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
C02555 00334 ∂08-Oct-88 2043 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 4)
C02570 00335 ∂08-Oct-88 2055 X3J13-mailer Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
C02585 00336 ∂08-Oct-88 2106 X3J13-mailer PRINT-CIRCLE-STRUCTURE (Version 3)
C02593 00337 ∂08-Oct-88 2112 X3J13-mailer DRAFT Issue: PROCLAIM-LEXICAL (Version 8)
C02615 00338 ∂08-Oct-88 2134 X3J13-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 2)
C02624 00339 ∂08-Oct-88 2146 X3J13-mailer Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
C02629 00340 ∂08-Oct-88 2129 X3J13-mailer DRAFT Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02657 00341 ∂08-Oct-88 2159 X3J13-mailer DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)
C02661 00342 ∂08-Oct-88 2203 X3J13-mailer DRAFT Issue SYMBOL-MACROLET-SEMANTICS, Version 4
C02670 00343 ∂08-Oct-88 2211 X3J13-mailer DRAFT Issue: TAILP-NIL (Version 2)
C02678 00344 ∂08-Oct-88 2211 X3J13-mailer DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
C02687 00345 ∂08-Oct-88 2153 X3J13-mailer Issue: SETF-SUB-METHODS (Version 5)
C02714 00346 ∂08-Oct-88 2159 X3J13-mailer DRAFT Issue: STREAM-INFO (Version 5)
C02740 00347 ∂08-Oct-88 2216 X3J13-mailer DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
C02749 00348 ∂09-Oct-88 0230 X3J13-mailer Draft Issue: CLOS-CONDITIONS (Version 3)
C02764 00349 ∂14-Oct-88 1427 X3J13-mailer Issue: RANGE-OF-COUNT-KEYWORD (Version 3)
C02775 00350 ∂18-Oct-88 2146 CL-Cleanup-mailer DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
C02777 00351 ∂25-Oct-88 0852 X3J13-mailer Proposed US Position Statement
C02783 00352 ∂25-Oct-88 1405 X3J13-mailer Comments on Cleanup issues due within two weeks
C02786 00353 ∂26-Oct-88 1925 X3J13-mailer Proposed US Position Statement
C02788 00354 ∂28-Oct-88 0347 X3J13-mailer mailing list update
C02789 00355 ∂01-Nov-88 1237 X3J13-mailer March meeting
C02791 00356 ∂01-Nov-88 1245 X3J13-mailer March meeting
C02793 00357 ∂02-Nov-88 0930 X3J13-mailer Hawaii hotel reservations reminder
C02795 00358 ∂02-Nov-88 1612 X3J13-mailer Re: Proposed US Position Statement
C02803 00359 ∂07-Nov-88 0639 X3J13-mailer Re: Proposed US Position Statement
C02805 00360 ∂07-Nov-88 1517 X3J13-mailer US Position Statement (Version 2)
C02814 00361 ∂09-Nov-88 1137 X3J13-mailer Official US Position
C02822 00362 ∂14-Nov-88 0804 X3J13-mailer Re: Hawaii hotel reservations reminder
C02824 00363 ∂14-Nov-88 1130 X3J13-mailer Ignore that message
C02825 00364 ∂20-Nov-88 0359 X3J13-mailer Phase 1 standard
C02827 00365 ∂29-Nov-88 1235 X3J13-mailer ISO Meeting Report
C02854 00366 ∂02-Dec-88 2351 X3J13-mailer re: ISO meeting report
C02862 00367 ∂05-Dec-88 1209 X3J13-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C02899 00368 ∂05-Dec-88 1238 X3J13-mailer Another Report on ISO/WG16
C02909 00369 ∂05-Dec-88 1249 X3J13-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 4)
C02919 00370 ∂05-Dec-88 1531 X3J13-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
C02927 00371 ∂05-Dec-88 1641 X3J13-mailer Issue: DEFPACKAGE (Version 7)
C02948 00372 ∂06-Dec-88 0810 X3J13-mailer Re: ISO meeting report
C02953 00373 ∂07-Dec-88 1425 X3J13-mailer January agenda items please
C02955 00374 ∂07-Dec-88 1659 X3J13-mailer Issue: DESCRIBE-INTERACTIVE (Version 4)
C02966 00375 ∂07-Dec-88 1803 X3J13-mailer Issue: DOTTED-MACRO-FORMS (Version 3)
C02975 00376 ∂07-Dec-88 2058 X3J13-mailer Issue: EXPT-RATIO (Version 2)
C02981 00377 ∂07-Dec-88 2143 X3J13-mailer Issue: FORMAT-PRETTY-PRINT (Version 7)
C02991 00378 ∂08-Dec-88 0613 X3J13-mailer Re: January agenda items please
C02993 00379 ∂08-Dec-88 1056 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5)
C03002 00380 ∂08-Dec-88 1129 X3J13-mailer Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
C03008 00381 ∂08-Dec-88 1147 X3J13-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (Version 7)
C03031 00382 ∂08-Dec-88 1524 X3J13-mailer Issue: HASH-TABLE-TESTS (Version 2)
C03039 00383 ∂08-Dec-88 1644 X3J13-mailer Issue: LCM-NO-ARGUMENTS (Version 1)
C03042 00384 ∂08-Dec-88 1643 X3J13-mailer Issue: LAMBDA-FORM (Version 4)
C03052 00385 ∂08-Dec-88 1716 X3J13-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 5)
C03062 00386 ∂08-Dec-88 1739 X3J13-mailer Issue: NTH-VALUE (Version 4)
C03068 00387 ∂08-Dec-88 2041 X3J13-mailer Issue: PACKAGE-DELETION (Version 5)
C03082 00388 ∂09-Dec-88 0039 X3J13-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 6)
C03089 00389 ∂09-Dec-88 0057 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
C03110 00390 ∂09-Dec-88 0119 X3J13-mailer Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
C03112 00391 ∂09-Dec-88 0059 X3J13-mailer Issue: SETF-PLACES (Version 1)
C03144 00392 ∂09-Dec-88 0119 X3J13-mailer Issue: FUNCTION-DEFINITION (Version 2)
C03153 00393 ∂09-Dec-88 0133 X3J13-mailer Issue: STREAM-ACCESS (Version 2)
C03164 00394 ∂09-Dec-88 1008 X3J13-mailer Issue: STREAM-INFO (Version 6)
C03189 00395 ∂09-Dec-88 1047 X3J13-mailer Issue: SYMBOL-MACROLET-DECLARE (Version 2)
C03194 00396 ∂09-Dec-88 1047 X3J13-mailer Issue: SYMBOL-MACROLET-SEMANTICS (Version 5)
C03204 00397 ∂09-Dec-88 1407 X3J13-mailer Caveat on "From: cl-cleanup..."
C03206 00398 ∂09-Dec-88 1406 X3J13-mailer Issue: TAGBODY-CONTENTS (Version 5)
C03215 00399 ∂09-Dec-88 1531 X3J13-mailer Issue: TEST-NOT-IF-NOT (Version 2)
C03225 00400 ∂09-Dec-88 1605 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
C03235 00401 ∂09-Dec-88 1618 X3J13-mailer Issue: VARIABLE-LIST-ASYMMETRY (Version 3)
C03241 00402 ∂09-Dec-88 1705 X3J13-mailer Issue: DECLARATION-SCOPE (Version 4)
C03268 00403 ∂09-Dec-88 1742 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 8)
C03280 00404 ∂10-Dec-88 0348 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
C03282 00405 ∂10-Dec-88 0513 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 8)
C03286 00406 ∂10-Dec-88 1236 X3J13-mailer ISO Meeting Status
C03288 ENDMK
C⊗;
∂09-Oct-86 0616 jjohnson@mitre.ARPA ANSI X3J13 committee
Received: from MITRE.ARPA by SAIL.STANFORD.EDU with TCP; 9 Oct 86 06:15:52 PDT
Date: Thu, 9 Oct 86 09:14:26 edt
From: jjohnson@mitre.ARPA (Jerry Johnson)
Full-Name: Jerry Johnson
Message-Id: <8610091314.AA20136@mitre.ARPA>
Organization: The MITRE Corp., Washington, D.C.
To: common-lisp-request@su-ai.ARPA, mathis@b.isi.edu, rpg@sail.stanford.edu,
x3j13@sail.stanford.edu
Subject: ANSI X3J13 committee
Cc: jjohnson@mitre.ARPA
Greetings to all recipients of this message. I would appreciate your including
me on any correspondence concerning the standardization of Common Lisp within
ANSI and any other countries contributions to this ISO effort since I
am MITRE's representative on the X3J13 committee.
Sincerely,
Jerry Johnson
MITRE Corporation
AI Center
Mail Stop W418
1820 Dolley Madison Blvd
McLean, VA 22102
703-883-7173
∂09-Oct-86 1136 RPG Greetings
To: x3j13@SAIL.STANFORD.EDU
I am sending this message to reassure you that the X3J13
mailing list exists. The net address is:
x3j13@sail.stanford.edu
and the request address is
x3j13-request@sail.stanford.edu
-rpg-
∂10-Oct-86 1547 @REAGAN.AI.MIT.EDU:Hewitt@XX.LCS.MIT.EDU Meeting conflict
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Oct 86 15:47:04 PDT
Received: from DUE-PROCESS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 6231; Fri 10-Oct-86 18:44:00 EDT
Date: Fri, 10 Oct 86 18:44 EDT
From: Carl Hewitt <Hewitt@XX.LCS.MIT.EDU>
Subject: Meeting conflict
To: x3j13@SAIL.STANFORD.EDU
cc: Hewitt@XX.LCS.MIT.EDU
Message-ID: <861010184419.6.HEWITT@DUE-PROCESS.AI.MIT.EDU>
Folks,
I will be able to attend the next meeting on December 10 and 11 but not Dec.
12 because I have two scheduling conflicts on the 12th (it's my birthday and I
have to be present at another conflicting meeting on Friday the 12th).
--Carl
∂27-Oct-86 0653 MATHIS@ADA20.ISI.EDU X3J13 Meeting Dallas Dec 10-12
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 86 06:53:28 PST
Date: 27 Oct 1986 06:30-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: X3J13 Meeting Dallas Dec 10-12
From: MATHIS@ADA20.ISI.EDU
To: X3J13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU]27-Oct-86 06:30:46.MATHIS>
The second meeting of X3J13 will be held from 1pm, Wednesday,
December 10, 1986, until noon, Friday, December 12, 1986, at the
Sheraton Park Central in Dallas, Texas. Arrangements have been
made by Ellen Waldrum of Texas Instruments.
Many aspects of these early meetings are attempts to determine
the best things for this committee. There was some feeling that
this three day format was better than a two day format from both
travel and work perspectives. Having the meeting in a hotel makes
somethings easier, but it also makes the meal service more
expensive. TI graciously offered to help offset some of these
costs, but I thought that was the wrong precedent to be setting.
At the first meeting, it seemed that most people brought lunches
back to the meeting room so they could keep discussing various
issues; that is why we arranged a lunch for Thursday. At every
other TI sponsored meeting I have ever attended (once before)
there was an informal dinner (everyone ordering from the menu and
paying their own) at the Trail Dust (which is good and very
informal). We could make these arrangements for Wednesday night.
All of these food arrangements are optional.
Other aspects of the meeting (agenda, discussion papers, etc.)
will be covered in subsequent messages. -- Bob Mathis
The following is from Ellen Waldrum:
X3J13 December Meeting Registration Form; mail to:
Beverly Williams
Texas Instruments
P.O. Box 655474
MS 3651
Dallas, Texas 75265
A block of rooms is available at the Sheraton Park Central. The
rate will be $60 a night (plus tax). Please check the
appropriate dates and supply a credit card number if you wish to
have the room guaranteed. Coffee, juice, breakfast rolls, and
fruit will be available for the morning sessions and coffee and
soft drinks will be available for the afternoon sessions. Lunch
has been arranged for the Dec. 11 meeting. The cost per person
for this food service is $25. Please include a check for this
amount with the registration form if you wish to partake. Delta
Airlines has agreed to give participants a 40% discount.
Unfortunately, the reference number needed for reservations is
not available yet. It will be posted to the X3J13 mailing list
as soon as it is known. There has been some interest expressed
in having a group dinner at the Trail Dust the evening of Dec.
10 with an extra cost. If enough people want to participate,
reservations will be made. If you are interested, please note
this in the appropriate space below. If you have questions about
room or airline reservations, please call Beverly at
214-997-2108. Questions of a more general nature about the
arrangements should be directed to Ellen Waldrum at 214-995-6716
or net mail address Waldrum%TI-CSL@CSNET-RELAY.
Name:
------------------------------------------------------
Institution:
----------------------------------------------
Street Address:
--------------------------------------------
City: State: Phone:
----------------- ---- ----------------
Reservations: Dec. 9: Dec. 10: Dec. 11:
----- ----- -----
Credit Card: AE MC Visa Number:
--- --- --- ---------------------
Food Service: Yes No
--- ---
(Please make check payable to Texas Instruments)
Dinner at Trail Dust: Yes No
---- ----
The room rate is only guaranteed for reservations made before
November 17 so please mail this form as soon as possible.
∂05-Nov-86 0723 MATHIS@ADA20.ISI.EDU x3j13 second mailing
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 86 07:23:18 PST
Date: 5 Nov 1986 07:14-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: x3j13 second mailing
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Nov-86 07:14:06.MATHIS>
I just sent out in US mail the second x3j13 mailing. In it I
said you should also have seen it on this electronic address.
Due to a computer problem (which you don't want to hearabout) I
am unable to send you the total information electronically; I am
however still able to communicate somewhat on the net.
If you have anything you want sent out before the next meeting I
should have it by November 14. In this case hardcopy that I
could photocopy would be helpful.
Remember to send in your hotel reservations for the Dallas
meeting.
-- Bob
∂14-Nov-86 1137 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Delta reference number
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Nov 86 11:36:55 PST
Received: from ti-csl by csnet-relay.csnet id af01601; 13 Nov 86 8:10 EST
Received: from Puff (puff.ARPA) by tilde id AA04521; Wed, 12 Nov 86 16:05:10 cst
To: x3j13@SU-AI.ARPA
Cc: waldrum%ti-csl.csnet@RELAY.CS.NET
Subject: Delta reference number
Date: 12-Nov-86 15:59:39
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2741205578@Puff>
I had just sent the previous message when my phone rang.
Of course it was Beverly calling with the number I had
just told you was not available yet. To take advantage
of the Delta Airlines discount, you must make your
reservations through the Delta convention desk. The
phone number is 800-241-6760 and the reference file
number is B0238. We are listed with them as the
Computer Science Show. This discount is only good for
reservations made at least seven days in advance and
there are no penalties for cancellation. If you have
any questions or problems, please call Beverly or me
or send mail (Waldrum%ti-csl@csnet-relay).
-- Ellen
∂14-Nov-86 1136 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET December Meeting
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Nov 86 11:36:26 PST
Received: from ti-csl by csnet-relay.csnet id ae01601; 13 Nov 86 8:08 EST
Received: from Puff (puff.ARPA) by tilde id AA03964; Wed, 12 Nov 86 15:49:14 cst
To: x3j13@SU-AI.ARPA
Cc: waldrum%ti-csl.csnet@RELAY.CS.NET
Subject: December Meeting
Date: 12-Nov-86 15:43:45
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2741204624@Puff>
If you are not able to mail your form in time to meet the
November 17 deadline and wish to make a reservation, you
should call Beverly Johnson at 214-997-2108 and give her
the pertinent information. If you do call Beverly, please
send the form anyway as verification.
The Delta airlines reference number is still not available.
All of the paperwork is done but Delta has not provided this
bit of pertinent information yet. It will be posted as soon
as we get it and Beverly will be calling those of you who have
already inquired.
-- Ellen
∂25-Nov-86 1302 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Reservation confirmation
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Nov 86 13:02:34 PST
Received: from ti-csl by csnet-relay.csnet id ad04601; 25 Nov 86 15:42 EST
Received: from Puff (puff.ARPA) by tilde id AA23037; Tue, 25 Nov 86 13:32:15 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Reservation confirmation
Date: 25-Nov-86 13:28:28
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2742319706@Puff>
I have received reservation forms from the following
people:
Beckerle, Michael Hadden, George
Boelk, Mary Haflich, Steve
Brown, Gary Hewitt, Carl
Cugini, John Kiczales, Gregor
Daniels, Andrew Loeffler, David
Dussud, Patrick Margolin, Barry
Dabrowski, Christopher Perdue, Crispin
Ennis, Susan Rand, Douglas
Fahlman, Scott Rosenking, Jeffrey
Foderaro, John Wegman, Mark
Gabriel, Richard Wieland, Alexis
The following people have made reservations by phone
but the form has not yet arrived:
Beman, Richard Moon, David
Clinger, Will Vandeusen, Mary
Goldstein, Brad Weinreb, Dan
Masinter, Larry White, Jon
If your name is not in one of these lists and you
think it should be, please let me know ASAP.
Thanks,
Ellen
Waldrum%ti-csl@csnet-relay
214-995-6716
P.S. I will have receipts for the checks available
at the meeting.
∂27-Nov-86 1355 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Additional reservations
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 27 Nov 86 13:55:32 PST
Received: from ti-csl by csnet-relay.csnet id bz12469; 27 Nov 86 16:45 EST
Received: from Puff (puff.ARPA) by tilde id AA09163; Wed, 26 Nov 86 15:41:43 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Additional reservations
Date: 26-Nov-86 15:36:49
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2742413804@Puff>
When I send the original list of reservations, a
few names were inadvertently omitted. The following
people have also made phone reservations, but the
paperwork has not yet arrived:
Antonisse, James
Bobrow, Danny
Chaihalloux, Jerome
Giansiracusa, Bob
Mathis, Bob
Ohlander, Ron
Pitman, Kent
Steele, Guy
I have received a reservation form from Mary Van Deusen.
-- Ellen
∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU meeting in Dallas
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:33:15 PST
Date: 5 Dec 1986 11:46-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: meeting in Dallas
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 11:46:24.MATHIS>
I have just sent out some last minute documents. I hope that you
have all made your arrangements. Two messages follow: first is
cover letter on that mailing; second is draft agenda outline. If
you have any questions or comments, please be in touch. -- Bob
∂05-Dec-86 1734 MATHIS@ADA20.ISI.EDU Dallas meeting draft agenda outline
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:34:02 PST
Date: 5 Dec 1986 12:00-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Dallas meeting draft agenda outline
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 12:00:32.MATHIS>
agenda header -- 1
1 Call to Order, December 10, 1:00pm
2 Opening Remarks and Introductions
3 Approval of Agenda
4 Approval of Minutes of Sept 23-24 Meeting (Doc: 86-???)
5 Report on International Activities (Doc: 86-017)
6 Other Liaison Reports
7 Review of Goals and Objectives (Doc: 86-005)
8 Brief Overview of Technical Topics on Agenda
9 Recess, 5:00pm
agenda header -- 2
10 Call to Order, December 11, 9:00am
11 Function/Value Cells (Doc: 86-010)
12 Relationship of Common Lisp and Scheme
13 European approach to defining via levels
14 LUNCH Second Day, 12:00-1:00pm
15 Error Systems (Doc: 86-011, 86-012, 86-013, 86-014)
16 Update on object system discussions (Doc: 86-018)
17 Handling technical discussions
18 Recess, 5:00pm
agenda header -- 3
19 Call to Order, December 12, 9:00am
20 Summary of Technical Issues and Discussions
21 Planning Relative to Other Technical Issues
22 Call for Officer Candidates
23 Future Meeting Schedule (Doc: SD-04)
24 Review of Action Item Assignments
25 Adjournment, 12:00noon
∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU third mailing cover letter
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:33:25 PST
Date: 5 Dec 1986 11:56-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: third mailing cover letter
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 11:56:16.MATHIS>
Doc. No.: X3J13/86-015
Date: December 1, 1986
Project: X3J13 Common Lisp
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
Ph: (703)425-5923
Mathis
X3J13 Members, alternates, observers, and potential participants:
This is a last minute reminder of the next meeting in Dallas on
December 10-12, 1986. If you have yet to make your reservations,
call Beverly at TI at (214)997-2108 or for general information,
Ellen Waldrum at (214)995-6716.
1. The minutes of first meeting have been delayed due to an
unforeseen sequence of unforeseeable circumstances which should
have been predictable. They are promised for the meeting in
Dallas.
2. Enclosed with this letter are the preliminary papers on
function cells and error systems.
3. At the ISO/TC97/SC22 Advisory Group meeting in Vienna, it was
decided to move ahead for a new work item on Lisp with a convenor
coming from France and a project editor coming from the United
States. This will be an item for discussion at the Dallas
meeting.
4. I had the opportunity to meet with Cathie Kachurik of the X3
Secretariat and Gary Robinson of DEC (who also happens to be
quite active in X3 and ISO/TC97) about the use of the Steele book
as a basis for the eventual standard. This issue was the basis
for some motions at the last meeting, which at the current time
are out of order. In our general discussions of goals and
objectives for the X3J13 committee, we need to discuss the actual
form we envision for the eventual standard and how closely it may
be related to the Steele book or to other manuals which have been
developed by other companies.
5. Remember that after this second meeting, we will have to
propose to X3 a set of officer candidates for X3J13. If anybody
wants to serve they should be prepared to make it known at this
meeting.
6. There will be a detailed proposed agenda at the start of the
meeting, but for your planning: Wednesday afternoon will include
brief overviews of the various topics on the agenda and an
extended discussion of goals and objectives for X3J13; Thursday
morning will begin with the function/value cell discussion;
Thursday afternoon will begin with the error system discussion;
and Friday morning will be devoted to finishing up remaining
topics.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
Attachments:
X3J13/86-010 "Issues of Separation in Function Cells and Value
Cells" by Gabriel and Pitman with others
X3J13/86-011 "Exceptional Situations in Lisp" by Pitman
X3J13/86-012 "Error Proposal #8 as of 8/4/86" by Pitman
X3J13/86-013 "Error Proposal #8 implementation suggestion as
of 8/4/86" by Pitman
X3J13/86-014 "Error Proposal Feedback up to 11/19/86"
∂05-Dec-86 1825 FAHLMAN@C.CS.CMU.EDU Logisitcs for Dallas meeting
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 18:25:39 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 5 Dec 86 21:25:36-EST
Date: Fri, 5 Dec 1986 21:25 EST
Message-ID: <FAHLMAN.12260501376.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: x3j13@SU-AI.ARPA
Subject: Logisitcs for Dallas meeting
I have a couple of questions about local arrangements for the Dallas
meeting. Could someone from TI send the following info to this mailing
list. (My apologies if this info was in some earlier mailing -- I can't
seem to find it if so. Maybe it was on the reservation form, which I
mailed in and didn't copy.)
1. Mailing address and phone number of the Sheraton Park Central.
2. How to get there from DFW airport. Approximate price and time
required for a taxi. Is there any cheaper way to make the trip, such as
a hotel limo? A lot of us will probably be arriving 10 - noon on
Wednesday, and will be heading back to the airport after adjornment on
Friday.
Thanks,
Scott
∂08-Dec-86 0902 jjohnson@mitre.ARPA Re: meeting in Dallas
Received: from MITRE.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 86 09:00:46 PST
Date: Mon, 8 Dec 86 11:50:17 est
From: jjohnson@mitre.ARPA (Jerry Johnson)
Full-Name: Jerry Johnson
Message-Id: <8612081650.AA17339@mitre.ARPA>
Organization: The MITRE Corp., Washington, D.C.
To: MATHIS@ADA20.ISI.EDU, x3j13@SU-AI.ARPA
Subject: Re: meeting in Dallas
Bob
My new mailing address is
Jerry Johnson
MITRE Corp
Mail Stop W418
1820 Dolley Madison Blvd
McLean VA 22102
Jerry
∂10-Dec-86 0358 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Logistics for Dallas Meeting
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 10 Dec 86 03:57:48 PST
Received: from ti-csl by csnet-relay.csnet id ad02710; 10 Dec 86 6:34 EST
Received: from Puff (puff.ARPA) by tilde id AA00397; Mon, 8 Dec 86 17:37:01 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Logistics for Dallas Meeting
Date: 8-Dec-86 16:50:13
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2743455011@Puff>
Thanks for the suggestion, Scott.
The mailing address of the hotel is
Sheraton Park Central
12720 Merit Drive
Dallas, Texas 75251
and the phone number is 214-385-3000.
Taxi fare from DFW to the hotel should be
approximately $20. There is also a shuttle
service called The Link that charges $9.
The approximate travel time is 30 minutes.
-- Ellen
∂12-Dec-86 1900 MATHIS@ADA20.ISI.EDU Dallas meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 12 Dec 86 18:55:23 PST
Date: 12 Dec 1986 18:25-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Dallas meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU]12-Dec-86 18:25:14.MATHIS>
Thanks to everyone. I think we had a very productive meeting.
We have a lot of work to do in preparation for the March 16-18,
1987, meeting in Palo Alto. Let's keep the communication going.
Watch this space and help fill it. -- Bob Mathis
∂15-Dec-86 1630 RPG Contents of the X3J13 mailing list
To: x3j13@SAIL.STANFORD.EDU
Here they are:
rpg
#msg.msg[jnk,jmc]
hst
"uwmcsd1!marque!maxiv"@UNIX.MACC.WISC.EDU
coffee@AEROSPACE.ARPA
cugini@ICST-ECF
dabrowski@ICST-ECF
"J.Dalton%uk.ac.edinburgh"@CS.UCL.AC.UK
ffitch@RAND-UNIX
padget@RAND-UNIX
NGALL@BBNG.ARPA
"barmar%bco"@HI-MULTICS.ARPA
hadden@HI-MULTICS.ARPA
hemphill@NRL-AIC.ARPA
"uwmcsd1!marque!gregj"@RSCH.WISC.EDU
"fkunze%franz.uucp"@UCBVAX.Berkeley.EDU
"jkf%franz.uucp"@UCBVAX.Berkeley.EDU
"smh%franz.uucp"@UCBVAX.Berkeley.EDU
Baggins@IBM.COM
Brandon@IBM.COM
"marick%mycroft"@GSWD-VMS.ARPA
dougr@MIT-EDDIE.ARPA
"primerd!barryn"@MIT-EDDIE.ARPA
"mcvax!inria!chaillou"@seismo.CSS.GOV
"mcvax!inria!crcge1!neidl"@seismo.CSS.GOV
peck@SPAM.ISTC.SRI.COM
scherlis@VAX.DARPA.MIL
squires@VAX.DARPA.MIL
gls@ZARATHUSTRA.THINK.COM
Wegman@IBM.COM
antonisse@MITRE.ARPA
jjohnson@MITRE.ARPA
Wieland@MITRE.ARPA
Yonke@USC-ECL.ARPA
Ohlander@ISI.EDU
balzer@A.ISI.EDU
Mathis@A.ISI.EDU
berman@VAXA.ISI.EDU
masinter.pa@Xerox.COM
Adler.pa@XEROX.COM
Bobrow.pa@XEROX.COM
pavel.pa@XEROX.COM
daniels.pa@XEROX.COM
gregor.pa@XEROX.COM
Ricci.pa@XEROX.COM
Sye.pasa@XEROX.COM
vittal.pasa@XEROX.COM
"JerryB%OZ"@XX.LCS.MIT.EDU
Hewitt@XX.LCS.MIT.EDU
"willc%tekchips@tek.csnet"@RELAY.CS.NET
"sridhar%tekchips@tek.csnet"@RELAY.CS.NET
"angela%gmdtub.uucp@Germany.csnet"@RELAY.CS.NET
"Bartley%TI-CSL"@RELAY.CS.NET
"Bate%TI-CSL"@RELAY.CS.NET
"Dussud%AUSOME%TI-CSL"@RELAY.CS.NET
"ida%utokyo-relay.csnet"@RELAY.CS.NET
"Waldrum%TI-CSL"@RELAY.CS.NET
"TURBA%sperry-csd.csnet"@RELAY.CS.NET
bawden@MC.LCS.MIT.EDU
RG@MC.LCS.MIT.EDU
"mike%acorn"@LIVE-OAK.LCS.MIT.EDU
"RSG%OZ"@AI.AI.MIT.EDU
JAR@MC.LCS.MIT.EDU
Soley@MC.LCS.MIT.EDU
"edsel!eb"@NAVAJO.STANFORD.EDU
"edsel!jonl"@NAVAJO.STANFORD.EDU
"edsel!jlz"@NAVAJO.STANFORD.EDU
fahlman@C.CS.CMU.EDU
RAM@C.CS.CMU.EDU
sgadol@Sun.COM
Muchnick@Sun.COM
CPerdue@Sun.COM
"quintus!gehrig!bak"@Sun.COM
Moon@SCRC-STONY-BROOK.ARPA
KMP@SCRC-STONY-BROOK.ARPA
DLW@SCRC-STONY-BROOK.ARPA
Goldstein@SCRC-STONY-BROOK.ARPA
ACW@SCRC-STONY-BROOK.ARPA
chaowatkins@SCRC-STONY-BROOK.ARPA
griss@HPLABS.HP.COM
"DCM%HPFCLP"@HPLABS.HP.COM
chapin@hplabs.hp.com
Krall@MCC.COM
Loeffler@MCC.COM
"Brown%Bach.Dec.Com"@DECWRL.DEC.COM
slater@umbc2.umd.edu
∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU minutes of Dallas meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 06:07:53 PST
Date: 19 Dec 1986 05:51-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: minutes of Dallas meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]19-Dec-86 05:51:46.MATHIS>
Gary Brown has already sent me the draft minutes of the Dallas
meeting. They seem very good, but he and I are still double
checking each other. If you want to see the preliminary version,
I will forward it to you; if you would rather wait, they will
come in about ten days. -- Bob Mathis
∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU proposed purposes
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 06:07:38 PST
Date: 19 Dec 1986 05:46-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: proposed purposes
Subject: [Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
sigh, sigh! Guy got this done, but to me on a day I was off the
net. He has inserted some sight additions. We should discuss
this on the net so that we can make a clean copy with clearly
specified alternate wordings so that we could vote on it point by
point at the next meeting. In Dallas I got the feeling that if
we had a clean text, it would probably be passed unanimously.
This is the chance for all of you (particularly those who could
not be in Dallas) to participate in the discussion. -- Bob
Mathis
Begin forwarded message
Received: FROM GODOT.THINK.COM BY USC-ISIF.ARPA WITH TCP ; 16 Dec 86 09:46:39 PST
from boethius by Godot.Think.COM via CHAOS; Tue, 16 Dec 86 12:45:00 EST
Date: Tue, 16 Dec 86 12:46 EST
From: Guy Steele <gls@Think.COM>
To: mathis@ada20.isi.edu
Cc: gls@AQUINAS
Subject: [gls@Think.COM: X3J13 charter (proposed)]
Return-Path: <gls@Think.COM>
Message-ID: <861216124628.6.GLS@BOETHIUS.THINK.COM>
Sigh. I mailed this Friday evening, but to the wrong address.
--Guy
----------------------------------------------------------------
Purposes of X3J13 Committee (Proposed)
1. X3J13 is chartered to produce an American National
Standard for Common Lisp. It will codify existing practice,
provide extensions to facilitate portability of code among
diverse implementations, and establish normative Common Lisp
programming practice.
2. The committee will begin with the language described in
{\it Common Lisp: The Language} by Guy L. Steele Jr. (Digital
Press, 1984), which is the current {\it de facto} standard for
Common Lisp. Whenever there is a proposal for the standard to
differ from {\it Common Lisp: The Language}, the committee
shall weigh both future costs of adopting (or not adopting) a
change and costs of conversion of existing code. Aesthetic
criteria shall be a subordinate consideration.
3. The committee will address at least the following topics
in the course of producing the standard, in each case either
incorporating specific features or explaining why no action
was taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in {\it Common Lisp: The Language}
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in {\it Common Lisp: The
Language} that require resolution. Topics (d) and (e) are not
addressed by {\it Common Lisp: The Language} but appear to be
well-understood and ready for standardization. Topics (f)-(i)
concern areas where standardization is desirable but not
crucial to production of a standard. Topic (j) is an area of
current controversy within the Lisp community. Other topics
may be considered if specific proposals are received.
4. The committee recognizes that Lisp programming practice
will continue to evolve and anticipates the need for future
revisions and extensions to the standard. This may include a
family of Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
[Possible amendment: change the word "extensions" in the first
paragraph to "additional features".]
--------------------
End forwarded message
∂19-Dec-86 0727 FAHLMAN@C.CS.CMU.EDU proposed purposes
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 07:27:45 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 19 Dec 86 10:26:34-EST
Date: Fri, 19 Dec 1986 10:26 EST
Message-ID: <FAHLMAN.12264051413.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@ADA20.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU
Subject: proposed purposes
In-reply-to: Msg of 19 Dec 1986 08:46-EST from MATHIS at ADA20.ISI.EDU
Looks excellent to me.
The proposed ammendment (extensions -> additional features), seems like
a useful clarification.
-- Scott
∂19-Dec-86 0831 Bobrow.pa@Xerox.COM Re: proposed purposes
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Dec 86 08:31:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 DEC 86 08:31:11 PST
Date: 19 Dec 86 08:30 PST
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: proposed purposes
In-reply-to: MATHIS@ADA20.ISI.EDU's message of 19 Dec 86 05:46 PST
To: MATHIS@ADA20.ISI.EDU
cc: x3j13@SAIL.STANFORD.EDU
Message-ID: <861219-083111-7132@Xerox>
I like this very much -- with the suggested change:
extensions --> additional features
It captures both the need for resolving the current set of issues
relatively quicly for the current community, and also possible futures
that could involve more work, but provide great benefit.
danny
∂19-Dec-86 0936 ohlander@venera.isi.edu Re: proposed purposes
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:35:49 PST
Posted-Date: Fri 19 Dec 86 09:35:29-PST
Received: by venera.isi.edu (5.54/5.51)
id AA22770; Fri, 19 Dec 86 09:35:30 PST
Date: Fri 19 Dec 86 09:35:29-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: proposed purposes
To: MATHIS@ada20.isi.edu
Cc: X3J13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 19-Dec-86 09:35:29.VENERA.ISI.EDU>
In-Reply-To: Message from "MATHIS@ADA20.ISI.EDU" of 19 Dec 1986 05:46-PST
Looks good. I vote for the document with the change of "additional
features" to "extensions".
Ron
-------
∂19-Dec-86 0958 ohlander@venera.isi.edu Re: proposed purposes
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:58:18 PST
Posted-Date: Fri 19 Dec 86 09:43:35-PST
Received: by venera.isi.edu (5.54/5.51)
id AA22910; Fri, 19 Dec 86 09:43:36 PST
Date: Fri 19 Dec 86 09:43:35-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: proposed purposes
To: MATHIS@ada20.isi.edu
Cc: X3J13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 19-Dec-86 09:43:35.VENERA.ISI.EDU>
In-Reply-To: Message from "MATHIS@ADA20.ISI.EDU" of 19 Dec 1986 05:46-PST
Looks good. I vote for the document with the change of "extensions"
to "additional features."
Ron
-------
∂19-Dec-86 1155 berman@vaxa.isi.edu Re: proposed purposes,
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 11:55:25 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA17572; Fri, 19 Dec 86 11:55:23 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8612191955.AA17572@vaxa.isi.edu>
Date: 19 Dec 1986 1155-PST (Friday)
To: MATHIS@ADA20.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU
Subject: Re: proposed purposes,
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
In-Reply-To: Your message of 19 Dec 1986 05:46-PST.
<[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Me Like. Ugh.
RB.
∂19-Dec-86 1323 DLW@ALDERAAN.SCRC.Symbolics.COM proposed purposes
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 19 Dec 86 13:19:50 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 32441; Fri 19-Dec-86 15:52:55 EST
Date: Fri, 19 Dec 86 15:54 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: proposed purposes
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
To: MATHIS@ADA20.ISI.EDU, x3j13@SAIL.STANFORD.EDU
In-Reply-To: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Message-ID: <861219155422.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
This looks fine. The spelling of "ommissions" should omit one of the
m's. I agree that "extensions" should be changed to "additional
features".
∂19-Dec-86 2017 Moon@RIVERSIDE.SCRC.Symbolics.COM proposed purposes
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 19 Dec 86 20:17:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 87742; Fri 19-Dec-86 23:15:26 EST
Date: Fri, 19 Dec 86 23:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: proposed purposes
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
To: MATHIS@ADA20.ISI.EDU
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Message-ID: <861219231549.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think this is an excellent charter for X3J13. I approve of the
wording and especially of the attitude about what is important and the
choice to finish Common Lisp rather than embarking on a new experiment.
One comment on "establish normative Common Lisp programming practice":
I doubt it's actually possible to get such a large group of Lisp programmers
to agree in any meaningful way on issues of programming style. If this
goal is achieved, it will be a monumental accomplishment. My preference
would be to leave it to the professors and the authors of textbooks, but
I have no real objection. After all, some of the lettered items will be
fairly difficult to bring to closure too.
∂22-Dec-86 1849 hpfclp!dcm@hplabs.HP.COM Charter statement
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 22 Dec 86 18:49:07 PST
Received: by hplabs.HP.COM ; Mon, 22 Dec 86 14:07:40 pst
From: hpfclp!dcm@hplabs.HP.COM
Received: by hpfclp; Mon, 22 Dec 86 10:24:52 mst
Date: Mon, 22 Dec 86 10:24:52 mst
Return-Path: <hpfclp!dcm>
Received: from hpfcdcm.UUCP; Mon, 22 Dec 86 10:15 MST
To: hpfclp!x3j13@sail.stanford.edu
Subject: Charter statement
This may have already appeared from another source, I'm not sure since there
seems to be some problem with my mail address. Here is the text of Guy's
statement of purpose with some comments from the discussions. Words or
clauses that were topics of discussion are enclosed in []s. Additional notes
are indented after each item.
Dave Matthews
------------------------------------------------------------------------------
Revise draft 86-005
Purposes of X3J13 Committee (proposed)
1. X3J13 is chartered to produce an American National Standard for Common Lisp.
It will codify existing practice, provide [extensions] [necessary] to
[facilitate] portability of code among diverse implementations and [establish]
normative [Common] Lisp programming practice.
change establish to stabilize?
extensions is a loaded word, are they required or not, maybe features is
a better word?
should a stronger term than facilitate be used
are we really establishing a programming practice, including style, etc
2. The committee will begin with the language described in Common Lisp: the
Language by Guy L. Steele Jr., which is the current de facto standard for
Common Lisp. Whenever there is a proposal for the standard to differ from CLTL
the committee shall weigh both future costs of adopting (or not adopting) a
[feature] and costs of conversion of existing code. [Aesthetic criteria shall
be a subordinate consideration.]
feature might be better said as change
should the clause about aesthetics exist at all
3. The committee will address at least the following topics in the course of
producing the standard, in each case either incorporating specific features or
explaining why no action was taken:
a) repairing [errors/mistakes], ambiguities and minor omissions in CLTL
b) error handling/condition signalling
c) semantics of compilation
d) object-oriented programming
e) iteration [the LOOP] constructs
f) multiprocessing
g) graphics
h) windows
i) one or two name spaces for functions or values
j) validation
Topics (a)-(c) concern deficiencies in CLTL that require resolution. Topics
(d) and (e) are not addressed by CLTL but appear to be well-understood and
ready for standardization. Topics (f)-(h) concern areas where standardization
is desirable but not crucial to production of a standard. Topic (i) is an
area of current controversy in the LISP community.
Topic (j) is not currently clarified.
4. The committee recognizes that Lisp programming practice will continue to
evolve, and anticipates the need for future revisions and extensions to the
standard. This may include a family of Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international Lisp standard.
separated from item 4.
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU 2nd meeting minutes X3J13/86-021
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:27:05 PST
Date: 5 Jan 1987 17:12-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: 2nd meeting minutes X3J13/86-021
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:12:03.MATHIS>
DRAFT Minutes X3J13 Committee Meeting
Dates: December 10, 11, 12, 1986
Location: Sheraton Park Central Hotel, Dallas, Texas
Chair: Bob Mathis (acting)
Secretary: Gary Brown (acting)
Hour of opening: December 10, 1986 1:20 PM
Hour of adjournment: December 12, 1986 11:25 AM
List of Voting members: Attached
Approved Agenda: Attached (86-0016)
Approval of previous minutes: None were prepared
Register of Documents: Attached
Motions seconded and not withdrawn:
Motion to formally thank Ellen Waldrum and Texas Instruments for
the meeting arrangements.
Moved by Dave Slater
Seconded by Peter Coffee
Unanimously approved
Future meeting schedule:
The next meeting is scheduled for March 16, 17 and 18, 1987 in Palo
Alto, California. Dick Gabriel will make the arrangements.
List of action items assigned to committee members:
Working groups were formed for eleven areas requiring investigation
and a convenor was assigned for each group. These groups are
informally charged with bringing evaluation and recommendations back
to the full committee. The body of the minutes lists the groups
and their convenors.
Meeting Summary:
Call to Order:
The meeting was called to order at 1:20 PM.
Opening remarks:
Bob Mathis specified significant dates for X3J13:
December 30, 1986: Wrapup mailing for second meeting
January 9, 1987: Minutes for second meeting due
January 15, 1987: Membership fees due (however no one has
yet received bills)
February 4, 1987: Deadline for next meetings mailing
February 10, 1987: Mailing for meeting 3
Bob Mathis introduced himself discussed his background. All attendees
then introduced themselves.
Approval of agenda:
The agenda, X3J13/86-016, was approved without objection.
Approval of minutes:
The minutes of the first meeting (September 23-24) were not available.
Report on International Activities:
Bob Mathis attended SC22 in Vienna and reported on that meeting.
The major decision was that an ISO Lisp committee would be formed
with a convenor from France and a project editor from the United
States.
Dick Gabriel reported on the "EuLisp" meeting in Paris. The
"EuLisp" group intends to work through ISO and Christian Queinnec
would be group convenor. Several technical issues were also
discussed at the Paris meeting and it is obvious that there
are some technical differences between the initial "EuLisp"
proposal and Common Lisp.
Other liaisons reports:
Bob Mathis asked if there were any volunteers to review:
o Guidelines for programming language conformity and testing
o Programming language standards document standard (i.e. a standard
for how a standard should be written)
Mathis also reported that DEC Press would cooperate with X3J13 in
preparation of standards document. However, initial discussions
with ANSI on allowing the "free" distribution of the standard
document were not encouraging.
Review of Goals and Objectives (86-005):
Approximately an hour and a half was spent discussing the proposed
goal statement for X3J13. Issues raised included:
o the relationship between X3J13 and an ISO Lisp standard effort
o conservative vs ambitious planning and language design
o de-facto vs real standards
Various committee members contributed opinions and historical anecdotes.
No formal motions were made.
Overview of technical topics.
Dick Gabriel gave a brief overview of issues surrounding function
and value cell separation. Kent Pitman gave a overview of the
proposed condition handling system.
Recess:
The meeting was recessed on December 10, 1986 at 5:30 PM.
Call to Order:
The meeting was resumed on December 11, 1986 at 9:07 AM.
Function/Value Cells (86-010):
Dick Gabriel presented the technical issues raised in "Issues of
Separation in Function Cells and Value Cells" (86-010). This topic
was dsicussed for two and a half hours.
Lunch:
The meeting was recessed for lunch from 11:45 AM to 12:50 PM.
Goals and Objectives:
Danny Bobrow presented some alterations to the "Goals and Objectives".
These proposed changes included:
o Stating that X3J13 would work on two fronts; ANS standard for Common
Lisp and working with ISO to prodcue Lisp standard for the longer term.
o Stating we would address other areas such as windows, graphics and
multi-processing
Jerome Chailloux gave his opinions on the goals for X3J13.
Error Systems:
Kent Pitman presented a description of the proposed Common Lisp
Condition handling system. Discussions lasted an hour and fifteen
minutes. Kent believes this proposal is relatively firm and a
final specification will be available soon.
Update on object systems:
Danny Bobrow presented the status of the proposed Common Lisp
object subsystem. The major change between current design and
what was previously proposed is no longer using DEFSTRUCT for
object definition but instead using two new macros; DEFRECORD and
DEFCLASS. Danny believes that this work is progressing well and
expects convergence before the next meeting.
Goal and Objectives:
Approximately half an hour was spent in another open discussion
X3J13 of Goals and Objectives. Bob Mathis suggested that an
ANS standard separate from ISO might be rejected by X3.
Recess:
The meeting was recessed on December 11, 1986 at 5:15 PM.
Call to Order:
The meeting was resumed on December 12, 1986 at 9:10 AM.
The committee voted to formally thank Ellen Waldrum and Texas
Instruments for the meeting arrangements.
Handling Technical Issues:
Bill Scherlis reported on the reccommendations of a subgroup formed
to discuss effective ways for X3J13 to discuss and decide issues.
They suggested that small working groups be formed to:
o Prepare briefings for the entire committee
o Evaluate the costs and benefits of alternative
o Make recommendations for appropriate action.
The following task groups were suggested. The person speicified is
the acting chair for each group [other initial members are listed].
1. Steele book cleanup Scott Fahlman
[Matthews, Pitman, White, Maisinter, Steele]
2. Lisp1/Lisp2 Dick Gabriel
[Pitman, Clinger, Wegman, Giansiracusa, Weinreb]
3. Objects Danny Bobrow
[Gabriel, Moon, Dusaud, Gregor, Keen, DeMicale]
4. Errors and conditions Kent Pitman
[Daniels]
5. Validation and conformance Rich Berman
[Beckerle, Slater, White]
6. Types and declarations Bill Scherlis
[Curtis, Slater, Poser]
7. Macros Kent Pitman
[Haflich, Wegman]
8. Compiler specification Steve Haflich
[Beckerle, Bartly, MacLaughlin]
9. Presentation of standard Gary Brown
[Matthews, Lieberman, Ohlander, Rosenking, Boelk, Ennis]
10. Graphics and windows Doug Rand
[Masinter, Hadden, Waldrum, Debrowski]
11. Iteration JonL White
[Weinreb, Perdue]
Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed.
Goal and Objectives:
Guy Steele presented the recommendation of a subgroup formed
to create another draft of the Goals and Objectives statement for
X3J13. Here is a draft of this document:
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice, provide
features to facilitate portability of code among diverse
implementations and establish normative Common Lisp practice.
2. The committee will begin with the language described in "Common
Lisp: the Language" by Guy L. Steele Jr., which is the current
"de facto" standard for Common Lisp. Whenever there is a
proposal for the Standard to differ from CLtL, the committee
shall weigh both future costs of adopting (or not adopting)
a change and costs of conversion of existing code. Aesthetic
criteria shall be a subordinate consideration.
3. The committee will address at least the following topics
in the course of producing the standard, in each case either
incorporating specific features or explaining why no action
was taken:
(a) Repairing mistakes, ambiguities and minor omissions in CLtL
(b) Error handling/condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration construct(s)
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) One or two namespaces for functions and values
(j) Validation
Topics (a)-(c) concern deficiencies in CLtL that require resolution.
Topics (d) and (e) are not addressed by CLtL but appear to be
well understood and ready for standarization. Topics (f)-(h)
concern areas where standarization is desirable but not crucial
to production of a standard. Topic (i) is an area of current
controversy within the Lisp community. Other topics may be
considered if specific proposals are received.
4. The comittee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
A discussion of this proposal took place followed by an informal
"sense of the committee" vote. The committee overwhelmingly
accepted this proposal. A final draft of this will be prepared
for a formal vote at the next meeting.
Call for officer candidates:
The following committee members are standing for X3J13 elected offices:
o Chair - Bob Mathis
o Vice-chair - Guy Steele
o International Representative - Dick Gabriel
Future meeting Schedule:
The next meeting will be March 16-18, 1987 in Palo Alto, California.
Adjournment:
The meeting was adjourned on December 12, 1986 at 11:25 AM.
Respectfully Submitted,
Gary L. Brown
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU proposed purposes X3J13/86-020
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:27:30 PST
Date: 5 Jan 1987 17:15-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: proposed purposes X3J13/86-020
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:15:45.MATHIS>
Purposes of X3J13 Committee (Proposed)
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice, provide
extensions [amendment: change the word "extensions" to
"additional features".] to facilitate portability of code among
diverse implementations, and establish normative Common Lisp
programming practice.
2. The committee will begin with the language described in Common
Lisp: The Language by Guy L. Steele Jr. (Digital Press, 1984),
which is the current de facto standard for Common Lisp. Whenever
there is a proposal for the standard to differ from Common Lisp:
The Language, the committee shall weigh both future costs of
adopting (or not adopting) a change and costs of conversion of
existing code. Aesthetic criteria shall be a subordinate
consideration.
3. The committee will address at least the following topics in
the course of producing the standard, in each case either
incorporating specific features or explaining why no action was
taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in Common Lisp: The Language
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in Common Lisp: The Language
that require resolution. Topics (d) and (e) are not addressed by
Common Lisp: The Language, but appear to be well-understood and
ready for standardization. Topics (f)-(i) concern areas where
standardization is desirable but not crucial to production of a
standard. Topic (j) is an area of current controversy within the
Lisp community. Other topics may be considered if specific
proposals are received.
4. The committee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU general letter X3J13/86-022
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:26:57 PST
Date: 5 Jan 1987 17:03-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: general letter X3J13/86-022
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:03:23.MATHIS>
Doc. No.: X3J13/86-022
Date: 86-12-30
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
To everyone on the X3J13 (Common Lisp) mailing list:
This letter is being sent out in three different configurations: by
electronic mail to <x3j13> at SAIL (to everyone on that list), by regular
mail with enclosures (to everyone who has given an indication of
participation), and by regular mail without enclosures (to those on the
mailing list who have never responded). People who receive this letter
without enclosures, need to respond to this letter to remain on the mailing
list. Membership on X3J13 is open, but is based on a commitment to
continuing participation.
The Draft minutes of the Dallas meeting are enclosed (Doc: X3J13/86-021).
Thanks to Gary Brown. Included there is the list of initial members in the
task groups we formed (this was also the content of a separate electronic
message). Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed. At least part of the reason for
not forming the ISO interaction group was that the US delegation to the ISO
working group has not been chosen. Anyone from X3J13 is eligible if they
can make the additional commitment to work, time and travel. If anyone is
interested (no commitment yet) in serving on the ISO delegation, please
contact me; Mathis, Gabriel, and Clinger have already expressed their
interest.
The acting chairs are to make sure that the members of their group
communicate with each other. If it is appropriate that a group set itself
an agenda and select a leader, the acting chair should make sure it
happens. Each of these groups will be called on for a BRIEF report at the
next meeting. If that report will be any more than just an affirmation of
existence, please contact me for scheduling.
As a separate document (Doc: X3J13/86-020) the draft proposed purposes are
also enclosed. This differs slightly from the version in the minutes; it is
X3J13/86-020 (or its revision) that we will be considering at the next
meeting. This has also been circulated electronically.
You (that is people who received enclosures with this letter or who respond
to this letter) will be sent the other documents resluting from the Dallas
meeting separately.
If you have any comments or other documents you want circulated before the
next meeting, please send them to me by February 4, 1987.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
∂06-Jan-87 0723 MATHIS@ADA20.ISI.EDU task groups
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 07:19:23 PST
Date: 6 Jan 1987 07:13-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: task groups
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 6-Jan-87 07:13:41.MATHIS>
This has been covered in my over messages, but
is also being sent separately for emphasis.
-- Bob
At the meeting in Dallas, we decided to form some subgroups
(working groups, task groups, committees, or whatever name). What
follows is a section from the draft minutes giving the initial
structure of these groups. (Thanks to Gary Brown for getting the
minutes ready so promptly.) Others are free to join these groups,
but the size of each group should remain reasonable and
individuals should recognize they are making a commitment by
joining.
Bill Scherlis reported on the recommendations of a subgroup
formed to discuss effective ways for X3J13 to discuss and decide
issues. They suggested that small working groups be formed to:
o Prepare briefings for the entire committee
o Evaluate the costs and benefits of alternative
o Make recommendations for appropriate action.
The following task groups were suggested. The person specified is
the acting chair for each group [other initial members are
listed].
1. Steele book cleanup Scott Fahlman
[Matthews, Pitman, White, Maisinter, Steele]
2. Lisp1/Lisp2 Dick Gabriel
[Pitman, Clinger, Wegman, Giansiracusa, Weinreb]
3. Objects Danny Bobrow
[Gabriel, Moon, Dusaud, Gregor, Keen, DeMicale]
4. Errors and conditions Kent Pitman
[Daniels]
5. Validation and conformance Rich Berman
[Beckerle, Slater, White]
6. Types and declarations Bill Scherlis
[Curtis, Slater, Poser]
7. Macros Kent Pitman
[Haflich, Wegman]
8. Compiler specification Steve Haflich
[Beckerle, Bartly, MacLaughlin]
9. Presentation of standard Gary Brown
[Matthews, Lieberman, Ohlander, Rosenking, Boelk,
Ennis]
10. Graphics and windows Doug Rand
[Masinter, Hadden, Waldrum, Debrowski]
11. Iteration JonL White
[Weinreb, Perdue]
Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed.
[At least part of the reason for not forming the ISO interaction
group was that the US delegation to the ISO working group has not
been chosen. Anyone from X3J13 is eligible if they can make the
additional commitment to work, time and travel. If anyone is
interested (no commitment yet) in serving on the ISO delegation,
please contact me; Mathis, Gabriel, and Clinger have already
expressed their interest.]
[The acting chairs are to make sure that the members of their
group communicate with each other. If it is appropriate that a
group set itself an agenda and select a leader, the acting chair
should make sure it happens. Each of these groups will be called
on for a BRIEF report at the next meeting. If that report will be
any more than just an affirmation of existence, please contact me
for scheduling.]
∂06-Jan-87 2157 edsel!bhopal!jonl@navajo.stanford.edu proposed purposes
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 21:56:12 PST
Received: by navajo.stanford.edu; Tue, 6 Jan 87 21:55:27 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01003; Tue, 6 Jan 87 21:48:53 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA16556; Tue, 6 Jan 87 21:46:18 PST
Date: Tue, 6 Jan 87 21:46:18 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8701070546.AA16556@bhopal.edsel.uucp>
To: navajo!MATHIS%ADA20.ISI.EDU@navajo.stanford.edu
Cc: navajo!x3j13%SAIL.STANFORD.EDU@navajo.stanford.edu
In-Reply-To: navajo!MATHIS@ADA20.ISI.EDU's message of 19 Dec 1986 05:46-PST
Subject: proposed purposes
[Sorry for the late entry of this comment -- I sent it out over two weeks
ago, and it got "bounced back" from some mail gateway at Stanford after
a few days of mailer problems; also, I've been "out of action" for
the past two weeks.]
Return-Path: <jonl>
Date: Fri, 19 Dec 86 11:27:59 PST
From: jonl (Jon L White)
To: navajo!MATHIS%ADA20.ISI.EDU
Cc: navajo!x3j13%SAIL.STANFORD.EDU
In-Reply-To: navajo!MATHIS@ADA20.ISI.EDU's message of 19 Dec 1986 05:46-PST
Subject: proposed purposes
At Dallas, there was question about the first paragraph wording:
". . . establish normative Common Lisp programming practice."
Just what does that mean? and how can a committee "establish" it?
Someone suggested that that phrase was a replacement for some nebulous
statement about "portability of programmers", or "portability of skills".
If that is indeed the goal, then it's hard to see how a committee can
"establish" it -- I remember a suggestion being offered to re-word the
whole sentence roughly as follows:
"It will codify existing practice, provide additional features to
enable the portability of code among diverse implementations,
and facilitate the establishment of normative Common Lisp
programming practice."
-- JonL --
∂15-Jan-87 1329 Mailer@XX.LCS.MIT.EDU Document 86-019
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Jan 87 13:29:03 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Jan 87 16:28-EST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 24905; 15 Jan 87 16:14:20-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 51643; Thu 15-Jan-87 14:31:21-EST
Date: Thu, 15 Jan 87 14:31 est
Sender: mike@acorn
To: x3j13@sail.stanford.edu
From: mike%acorn@mit-live-oak.arpa
Subject: Document 86-019
Note: You will be receiving hardcopy of the following from Bob Mathis.
----------------------------------------------------------------------
!
To: ANSI x3j13
From: Mike Beckerle, Gold Hill Computers
Date: 1/13/87
Subject: Document x3j13/86-019
Since my draft proposal which was hastily drawn up at the last x3j13
meeting, I have had time to reconsider several points in my proposal
for adding a few features to CL to support Higher-Order Functional
Programming. I have also decided to bring up the meta issue in this
forum.
The meta-issue is this: Would adding enough syntactic accommodation
to Common Lisp to make functional programming palatable defuse this
Lisp1 vs. Lisp2 debate enough? Or more optimistically, what level of
accommodation for programming with functionals would in fact defuse
this issue. For example, Would it be enough to provide the following:
Programs written in in a Lisp1 "educational/functional" dialect would
not be directly upwardly compatible with ANS Common Lisp; however,
the changes required would be straightforward to make and
syntactically convenient. (We know that they can't be automatic due
to use of EVAL.) I am particularly trying to address the issues of
Appendix B, section 6 of the "Issues..." paper.
What I'm trying to get at here is this: Why do people want a
"one-cell" lisp? Is it because it promotes/allows effective
programming using higher-order functions (style), because it is
more consistent/cleaner and therefore easier to understand and
teach (conceptual economy), because they are more familiar with a
one-cell lisp than a two cell lisp (momentum), because of a
purely aesthetic view that one cell is "better" (aesthetics),
because they don't like the name-capture problems of
common-lisp's so called "non-hygienic" macros (macrophobia), or
finally because they want political clout (politics).
My approach addresses that the push for lisp1 is due at least
partially to aesthetics but primarily is due to the style issue.
The following is a proposal for adding a small number of features
to Common Lisp to accommodate programming using higher-order
functions, or functionals. Functional programming is much easier
in a Lisp1 dialect than a Lisp2 dialect since functional
programming makes extensive use of functions as values. Common
Lisp's current (Funcall ...) and (Function ...) or #' syntax
makes functional programming particularly awkward. In addition
the fact that one cannot write an application which produces a
function in the car of a list representing an application is a
pain. [let's call this the "((f g) h)" problem.] These features
are intended to accommodate the functional style, without changing
the language too radically from the current status defined in
CLtL.
---------------------------------------------------------------------
!
Document x3j13/86-019
Accommodating Functional-Style Programming in Common Lisp.
Mike Beckerle
Gold Hill Computers
Jan. 6, 1986.
One of the primary motivations for use of Lisp1 dialects is the
ease of higher-order programming. Many of the examples of
effective programming practice in Lisp1 given in the "Issues of
Separation in Function and Value Cells" paper recently discussed
by x3j13 at the Dec. '86 meeting are exactly of this type.
Unfortunately, macro programming in Lisp1 dialects is not well
understood and is a subject of current research; nevertheless
macro programming is heavily entrenched in the Common lisp world.
As a result, the approach advocated in this proposal is to
provide some standard operators and macros which make programming
using higher-order functions in Common Lisp significantly easier.
The Changes to CL as defined in CLtL are enumerated here, after
which there are some examples.
Change 1:
To section 5.2. Functions
Function call forms should be changed to allow the lisp1 like
syntax of:
((f g) h)
((lambda (x) x) #'(lambda (y) y)) 10) => 10.
i.e., the "function" position of an application should be treated
specially only if it contains a SYMBOL. If it contains a list
beginning with something other than LAMBDA it should be
interpreted as an application itself.
The forms above should, in every sense of the word except syntax,
be equivalent to:
(funcall (f g) h)
and
(funcall ((lambda (x) x) #'(lambda (y) y)) 10))
in the current CL as per CLtL.
Essentially, whenever symbols are used as functions, their
function-cell definitions are used. Lambda expressions and
function applications can also be used as functions. Lambda
expressions evaluate to functions. Function applications must
evaluate to either functions or symbols. If they evaluate to
symbols, then (recursively) the function definition of that
symbol is used.
The CL spec can explain the purpose of this special treatment for
function-positioned symbols in terms of the name-capture problem
of macros. Inadvertant name capture is, after all, the only real
reason for the special distinction for funtion-positioned symbols.
!
Change 2: Section 7.1.1.
The FUNCTION special form will be optional in front of
lambda expressions regardless of where they appear in a
program text. (The obvious exception for within quoted lists
obviously applies here, but isn't worth mention.)
It is as if the following definition was part of the CL system
(Defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
The FUNCTION special form is needed only to distinguish between
the function and value of symbols which are either globally
referenced or locally bound using one of FLET, LABELS, MACROLET,
parameter passing, LET, LET*, and MULTIPLE-VALUE-BIND.
!
Change 3: Section 20.2
For syntactic convenience, the value cell of all CL symbols
which are defined as functions are defined to contain
the function object as well as the function cell.
E.g.,
(symbol-value 'mapcar) => #<compiled-function 1234>
(symbol-function 'mapcar) => #<compiled-function 1234>
This allows use of the CL symbols which name CL functions in
variable position without need for the FUNCTION special form as
in (mapcar list '(a b c) '(d e f)). If the value of the variable
"list" is locally bound to a function, possibly using let, then
the local definition will be used in accordance with the rules of
lexical scoping.
The primary change this requires is the renaming of certain
symbols of significance to the standard read-eval-print loop.
I suggest that the following renamings be used:
+ => +1
++ => +2
+++ => +3
- => -- or _ ;; this one's difficult to get a nice name for!
* => *1
** => *2
*** => *3
/ => /1
// => /2
/// =? /3
The behavior of these variables would be identical to the current
behavior of the old-named variables. I consider this change to
be simply cosmetic, aesthetic, etc. No program of any quality
(other than those written as read-eval-print loops by
implementors) ever uses these variables. (Unfortunately, the
Peter Principle dictates that the least significant point always
gets the most debate, so I'm prepared for absolute tirades on
this one! Please restrain yourselves!!!!!)
!
Change 4: Section 7.11. Use of Higher-order Functions
Organizationally, this seems to belong in the chapter 7
discussion, so I've proposed a new section for that chapter
in lieu of any guidelines for how to present standards proposals.
The text as a preliminary draft follows:
"Common Lisp provides some support for programming using higher-
order functions. These allow the programmer to partially hide the
distinction between function-cells and value-cells and to program
as if using a language where only one cell is associated with
each symbol. The objective is to make the syntax of higher-order
programs easier to read and understand. The abstraction that this
creates is not complete; it is possible for programs to detect
that there are separate function and value cells even when these
abstractions are used; however, the syntactic convenience of
using these forms where they are applicable is significant.
FUNCTIONAL Vars* {form}* [Macro]
The Functional macro is used to create an environment where the
variables in the list "Vars" can be used both as variables and
in function position within the body forms without need for the #' or
(function ...) operator, nor use of (funcall ...).
For example:
(defun doublemap (f g)
(functional (f g)
(lambda (list) (f (g (mapcar f list)
(mapcar g list))))))
(defun y (f) ;; the paradoxical combinator
(functional (f)
((lambda (x)
(functional (x)
(f (x x))))
(lambda (x)
(functional (x)
(f (x x)))))))
Here, notice that "f" and "g" are used both as variables
representing functions, and also as functions, as if defined by
FLET or LABELS.
One possible definition for FUNCTIONAL is:
(defmacro functional (vars &body body)
(let* ((bindings (mapcar #'(lambda (name)
`(,name (&rest args) (apply ,name args)))
vars)))
`(flet ,bindings
,@body)))
Implementation note: FUNCTIONAL can also be implemented
using MACROLET.
Care is required if FUNCTIONAL is used in programs which perform
side-effects on symbols via SYMBOL-FUNCTION or SYMBOL-VALUE. The
behavior of the resulting program can be difficult to predict."
!
Change 5: Section 7.1.1. (again)
Note: The following is the least kosher aspect of this proposal,
but I am including it anyway. Once again it is written as an
addition to section 7.1.1. Its intended use is for defining new
named functions which will be associated with both function and
value cells of symbols, thereby forming a consistent extention.
In general, use of side-effects within higher-order programs is
extremely tricky; one tends to program in a pure style out of
necessity.
SYMBOL-CONTENTS symbol [Function]
In order to facilitate programming in the functional style it is
often useful to ignore the function-cell/value-cell aspect of
symbols. Symbol-contents, if used consistently throughout an
entire program can facilitate this style of programming.
The function Symbol-contents can be used to extract or replace the
value of a symbol in a manner which is indifferent to the
normal CL distinction between function cells and value cells.
Symbol-contents returns the contents of the value-cell of the
symbol when used as an accessor. When used as an assigner
(with setf); however, the value assigned is placed into both
the function-cell, and the value-cell.
Symbol-contents cannot access nor assign (using setf) the value
of local symbol or function definitions created using let, flet, labels,
let*, etc. Only the global value can be accessed or modified.
It is an error to execute code which calls a function named by a symbol
where that symbol has been assigned a value other than a function object
via setf of symbol-contents.
(defun foobar (x) x)
(symbol-contents 'x) => #<unbound>
(setf (symbol-contents 'x) (lambda (x) (+ x x)))
(symbol-contents 'x) => #<function-object (lambda (x) (+ x x))>
(symbol-function 'x) => #<function-object (lambda (x) (+ x x))>
(symbol-value 'x) => #<function-object (lambda (x) (+ x x))>
(eq (symbol-function 'x) (symbol-value 'x)) => T
--------------------------------------------------------------------
!
Use of the Higher-order function extensions to CL.
To show the utility of these abstractions in higher order
programming, it is important to look at some example programs.
Hence, I have rewritten the examples in Appendix B of
the "Issues of Separation in Function Cells and Value Cells"
using Common Lisp with the proposed extensions.
;;;---------------------------------------------------------------------
;;; from Appendix B: "High-Order Procedures for Functional Abstractions"
;; our macro for making functional programming easier.
(defmacro functional (vars &body body)
(let* ((bindings (mapcar (lambda (name)
`(,name (&rest args) (apply ,name args)))
vars)))
`(flet ,bindings
,@body)))
;; a macro which obviates #' notation.
(defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
;; the symbol-contents function and its setf.
(defun symbol-contents (name)
(symbol-value name))
(defun set-symbol-contents (name value)
(setf (symbol-value name) value)
(setf (symbol-function name) value))
(defsetf symbol-contents set-symbol-contents)
;; a DEFINE macro, syntactic sugar to make the examples
;; more scheme-like. Doesn't put implicit blocks on lambda's,
;; doesn't handle local defines. This could be done, but we won't bother
;; here.
(defmacro define (name value)
`(setf (symbol-contents ',name) value))
;; misc.
(defun null? (x) (null x))
(defun future (x) x)
(defun assq (x y)
(assoc x y :test 'eq))
;;--------------------------------------------------------------------
!
;; The example programs.
;; these have been translated slightly from Scheme to Common Lisp
;; plus my suggested extentions.
(define sum
(lambda (f a next b)
(functional (f next)
(if (> a b)
0
(+ (f a)
(sum f (next a) next b))))))
(define integral
(lambda (f a b dx)
(functional (f)
(* (sum f (+ a (/ dx 2)) (lambda (x) (+ x dx)) b)
dx))))
(define map
(lambda (f x)
(functional (f)
(if (null x)
nil
(cons (f (car x))
(map f (cdr x)))))))
(define reduce
(lambda (f l)
(functional (f)
(if (null? (cdr l))
(car l)
(f (car l)
(reduce f (cdr l)))))))
(define pairs
(lambda (x k)
(functional (k)
(if (or (null? x) (null? (cdr x)))
(k nil x)
(pairs (cddr x)
(lambda (p r)
(k (cons (list (car x) (cadr x))
p)
r)))))))
(define reduce
(lambda (f x)
(functional (f)
(pairs x
(lambda (p r)
(if (null? p)
(car r)
(reduce f
(append (map (lambda (z)
(future (apply f z)))
p)
r))))))))
(defstruct (table-abstraction
(:constructor make-table-abstraction
(maker looker-up inserter))
(:conc-name nil))
maker looker-up inserter)
(defun hashfunction (n)
(lambda (x)
(mod (sxhash x) n)))
(define hashify
(lambda (n table-abstraction)
(let ((hash (hashfunction n))
(bucket-make (maker table-abstraction))
(bucket-lookup (looker-up table-abstraction))
(bucket-insert! (inserter table-abstraction)))
(functional (hash bucket-make bucket-lookup bucket-insert!)
(let ((make
(lambda ()
(let ((hashtable (make-array n)))
(dotimes (i n)
(setf (aref hashtable i)
(bucket-make)))
hashtable)))
(lookup
(lambda (key table)
(bucket-lookup key
(aref table
(hash key)))))
(insert!
(lambda (key table value)
(bucket-insert! key
(aref table (hash key))
value))))
(make-table-abstraction make lookup insert!))))))
(defun make-entry (key value) (cons key value))
(defun set-value! (vcell value) (rplacd vcell value))
(define alist-table-abstraction
(make-table-abstraction
(lambda () (list '*alist-table*))
(lambda (key table)
(cdr (assq key (cdr table)))) ;; alist of cons pairs
(lambda (key table value)
(let ((vcell (assq key (cdr table))))
(if vcell
(set-value! vcell value)
(rplacd table
(cons (make-entry key value)
(cdr table))))))))
(define hash-table-of-alists-abstraction-generator
(lambda (n) (hashify n alist-table-abstraction)))
(define hash-table-of-alists
(hash-table-of-alists-abstraction-generator 16))
(define two-level-hash-table-abstraction-generator
(lambda (m n table-abstraction)
(hashify m (hashify n table-abstraction))))
(define two-level-hash-table-of-alists-abstraction-1
(two-level-hash-table-abstraction-generator
128 256 alist-table-abstraction))
;;-----------------------------------------------------------------
My observation is that using the FUNCTIONAL abstraction along with the
ability to perform applications which syntactically look like "((f g) h)"
makes the enhanced CL version pretty close to the Lisp1 version at least
as far as syntactic aesthetics are concerned.
∂15-Jan-87 2015 Moon@STONY-BROOK.SCRC.Symbolics.COM Document 86-019
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Jan 87 20:15:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 44898; Thu 15-Jan-87 23:13:42 EST
Date: Thu, 15 Jan 87 23:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Document 86-019
To: mike%acorn@MIT-LIVE-OAK.ARPA
cc: x3j13@sail.stanford.edu
In-Reply-To: The message of 15 Jan 87 14:31 EST from mike%acorn@mit-live-oak.arpa
Message-ID: <870115231337.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 15 Jan 87 14:31 est
From: mike%acorn@mit-live-oak.arpa
I don't know if X3J13 is the right mailing list for technical discussions,
but I'd like to offer a few comments on your proposal. To avoid contributing
to total mail overload, I will abbreviate your proposal as much as possible
when referring to it.
Change 1: Function call forms should be changed to allow the lisp1 like
syntax of: ((f g) h)
i.e., the "function" position of an application should be treated
specially only if it contains a SYMBOL. If it contains a list
it should be interpreted as an application itself.
I think this is a good idea. It's a kludge, of course, and creates a
small inconsistency in the language (allowing list forms but not symbol
forms), however I think the ratio of benefit to harm is favorable.
Maclisp on the pdp-10 used to have a feature similar to this, but it was
removed because it caused a lot of problems. I believe the problems can
be traced to the fact that it allowed the result of evaluating a list or
efunctuating a symbol to be another list, which was then evaluated. The
question is, in what lexical scope should that list be evaluated. Your
proposal avoids this problem by forbidding repeated evaluation.
Your proposal allows repeated efunctuation (that is, the result of
evaluating a list can be a symbol, which is then efunctuated) and you
don't specify in what lexical environment the symbol is to be
efunctuated. CLtL is not very clear on this point; p.107 says that
APPLY efunctuates in the global lexical environment if given a symbol,
but otherwise the issue is not addressed as far as I can see. This
feature may not be essential to your proposal; you might want to remove
it.
(For those who haven't seen the term before, "efunctuate" is what the
FUNCTION special form does.)
Change 2: It is as if the following definition was part of the CL system
(defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
This is definitely a good idea and causes no problems.
Change 3:
For syntactic convenience, the value cell of all CL symbols
which are defined as functions are defined to contain
the function object as well as the function cell.
I don't think this is a good idea, because it creates an artificial
distinction between built-in CL functions and functions defined by
the user with DEFUN or LABELS. If the rule of storing the definition
in both cells applies to the latter type of functions too, then
we would just have Lisp1.
Change 4:
The Functional macro is used to create an environment where the
variables in the list "Vars" can be used both as variables and
in function position within the body forms without need for the #' or
(function ...) operator, nor use of (funcall ...).
This is a good idea. To me it seems that having this eliminates the
need for your change 3.
Change 5:
Symbol-contents returns the contents of the value-cell of the
symbol when used as an accessor. When used as an assigner
(with setf); however, the value assigned is placed into both
the function-cell, and the value-cell.
This stands or falls with change 3. Again, I think change 4 is
a better approach.
∂16-Jan-87 0822 FAHLMAN@C.CS.CMU.EDU Document 86-019
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87 08:21:50 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 16 Jan 87 11:21:29-EST
Date: Fri, 16 Jan 1987 11:21 EST
Message-ID: <FAHLMAN.12271401438.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU, x3j13@SAIL.STANFORD.EDU
Subject: Document 86-019
In-reply-to: Msg of 15 Jan 1987 23:13-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
This discussion should probably be on the Common-Lisp mailing list, but
since I'm responding to Moon's mail to this list, I'll do it here.
I agree totally with Moon on this one -- I was just about to write a
reply with essentially the same content as his, supporting the idea
except for parts 3 and 5.
If the goal is to make functional-style programming easier without
disrupting Common Lisp too badly, I think your proposals (minus numbers
3 and 5) do the job about 90% as well as a move to Lisp1. For those
people whose goal is to merge Common Lisp with Scheme and/or Eulisp,
then only a move to Lisp1 will do. However, unless great progress is
made on the macro issue and on ways of making the conversion less
painful, I think that a move to Lisp1 is unlikely; less radical
proposals such as yours are definitely worth considering.
I like this much better than the &function idea, by the way. that
seems very confusing and irregular to me.
-- Scott
∂16-Jan-87 1124 Masinter.pa@Xerox.COM Re: Document 86-019, &function, etc.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jan 87 11:24:34 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JAN 87 11:24:00 PST
Date: 16 Jan 87 11:24 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Document 86-019, &function, etc.
In-reply-to: various
To: x3j13@sail.stanford.edu
Message-ID: <870116-112400-2364@Xerox>
These proposals fail to meet what I believe is the primary goal of those
who want 1-lisp over 2-lisp, namely, to simplify and make more
consistent the programming language semantics, to reduce the number of
different kinds of references in the language.
Instead, they do the opposite. While superficially bearing some
resemblance to 1-lisp, there are more rules for evaluation rather than
fewer, the description of the language and its semantics is complex,
there are odd exceptions. (For example, in the
funcall-if-car-of-form-is-list proposal, what if the car of the form is
a macro? A macro that expands to a symbol? To a lambda?).
It does no good to pick some minor syntactic feature of 1-lisp,
implement that, and ignore the basic principle.
∂16-Jan-87 2155 willc%tekchips.tek.com@RELAY.CS.NET Re: Document 86-019
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 16 Jan 87 21:55:29 PST
Received: from tektronix.tek.com by csnet-relay.csnet id ab04827;
17 Jan 87 0:43 EST
Received: by tektronix.TEK.COM (5.31/6.18)
id AA04079; Fri, 16 Jan 87 21:25:51 PST
Received: by tekchips.TEK (5.31/6.16)
id AA12223; Fri, 16 Jan 87 14:56:26 PST
Message-Id: <8701162256.AA12223@tekchips.TEK>
To: x3j13@SU-AI.ARPA
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU
Subject: Re: Document 86-019
In-Reply-To: Your message of Thu, 15 Jan 87 14:31 est.
<8701160757.AA02526@tekchips.TEK>
Date: 16 Jan 87 14:56:21 PST (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
Mike Beckerle asked some interesting questions and suggested some possible
answers. Ultimately, he is asking for a philosophy of programming language
design. Here's mine.
* * *
Programming is hard because it's hard to know what you want the machine
to accomplish (the problem), and it's hard to know how to accomplish it
(the algorithm). If you knew these two things, it ought to be easy to
program the machine to do what you want.
It usually isn't. The reason is that you have to learn all sorts of arcane
things about the computing environment and programming language that you
use. These details have nothing to do with the problem you're trying
to solve. Even so, they may be almost as difficult to master.
Most people, being reasonable, don't try to master their programming
language completely, particularly if their programming language is big
and complicated. In my experience, the main thing that a programming
language can do for these people is to be consistent with a simple mental
model that they can use without getting into trouble. Extra features
that help people get their work done more easily are nice, but it is more
important that the language not get in their way. It is most important
that the language not be full of nasty surprises for its users.
This principle of programming language design is sometimes known as the
"Law of Least Astonishment", in waggish recognition of the fact that even
the best design efforts are ad hoc in part. Its motivation is very
pragmatic, its application very practical. It says that simplicity,
elegance, and aesthetics pay off.
* * *
In answer to some of Mike's specific questions, people prefer a single-
environment Lisp because of style, conceptual economy, and aesthetics; I
see little difference between conceptual economy and aesthetics, which is
perhaps a clue to my sense of aesthetics. Inertia can't be the reason,
since most of us who prefer the single environment were once more familiar
and comfortable with two-cell Lisps. Macros don't have anything to do with
this issue, so macrophobia can't be the reason; if anything, the problems
with Common Lisp-style macros are exacerbated by a single environment.
Speaking for myself, politics isn't the reason I prefer a single
environment; rather my preference for a single environment, the current
preponderance of political clout on the side of multiple environments,
and the use of that clout in the current push for Lisp standards are the
reasons I myself now seek political clout.
* * *
Mike's other question asks whether enough syntactic sugar could be added
to Common Lisp to make functional programming palatable. Well, Common
Lisp certainly could be improved in this respect, and I second David
Moon's remarks on changes 1 and 2.
As for changes 3, 4, and 5, these changes seem designed to make it possible
to program as though Common Lisp were a Lisp1 dialect, but they only go
part of the way. You might be able to go all the way by doing things like
defining the LAMBDA macro so it automatically wraps an equivalent of the
FUNCTIONAL macro around its body, by defining a SET! special form that
assigns to both the value and functional bindings (which, by the way, can't
easily be written in Common Lisp as it stands because only global functional
bindings can be assigned), and so on. This would amount to implementing
a Lisp1 sublanguage inside Common Lisp. Unless you're willing to go
all the way to that Lisp1 sublanguage, I think it's a bad idea to try
to paper over the fact that Common Lisp has multiple environments.
If the changes go only part of the way, and we teach people to use the
proposed syntax and encourage them to think about Common Lisp as though
it is a Lisp1 dialect, then they will probably end up getting burned
even more often than they do now. Even people who understand full well
that Common Lisp has multiple environments might slip into the cozier
Lisp1 mode of thought and get burned by the Lisp2 reality.
It's the law of least astonishment: A Lisp2 dialect that looks like a
Lisp1 dialect 98% of the time may be worse than a straightforward Lisp2
dialect.
Peace,
William Clinger
∂22-Jan-87 1732 RPG March X3J13 Meeting in Palo Alto
To: x3j13@SAIL.STANFORD.EDU
X3J13 Meeting
3/16/87 - 3/19/87
Palo Alto, CA
The third meeting of X3J13 will be held from 1pm, Monday, March 16, 1987
until noon, Wednesday, March 18, 1987, at the Hyatt Rickeys (not to be
confused with the Hyatt Palo Alto across the street) in Palo Alto, CA.
Meetings on Monday and Tuesday will be in the Camino Ball Room C and on
Wednesday the meeting will be in the Executive Conference Room. Come
early, California is beautiful in March.
A block of rooms is available at the Hyatt Rickeys. The rate will be $92 a
night (plus tax). If you prefer, they have rooms available for non-smokers
(ahh, a room never touched by smoke). Please check the appropriate dates
and supply a credit card number if you wish to have the room guaranteed.
Check in time is 3:00pm. Check out time is 12:00 noon. I will be taking
reservations until 2/15/87. After that time please contact Hyatt Rickeys
directly at (800) 228-9000 for reservations and changes. Be sure to
mention ``Standards Committee X3J13'' or ``Lucid.'' Reservations must be
received by the hotel no later than 2/15/87 to receive the discounted rate.
Refreshments will be available during the morning and afternoon sessions.
Lunch has been arranged for Tuesday, March 17. If you have dietary
restrictions please complete the appropriate section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
Delta Airlines has agreed to give us a 35% discount to San Francisco. Call
Delta (or have your travel agent call) toll free at 1 (800) 241-6760 daily
8:30am thru 8:00pm EST. Please refer to file number A0732 when calling.
Tickets must be purchased 14 days in advance, there is no minimum stay, and
the maximum stay is 14 days. Please confirm early as there is limited
seating.
I will be happy to arrange a group dinner at the Thai Garden (a different
eating experience) the evening of March 16 with an extra cost. If you are
interested, please note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
| |
|X Hyatt Rickey |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rushhour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-0800. Hertz, Avis and National car rentals are
within 1 block.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@navajo.stanford.edu
(415) 329-8400
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid, Inc. mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Reservations: Mar 15: ___ Mar 16: ___ Mar 17: ___
___ single (1 person) ___ double (2 persons, 1 bed)
___ twin (2 persons, 2 beds) ___ triple (three persons, 2 beds)
The $92.00 room rate is only guaranteed for reservations received by
February 15.
Credit Card: ___ AMEX ___VISA ___ Mastercard ___Diners ___CB
Number: ___________________________________________ Exp ____________
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Dinner at Thai Garden 3/16: yes _______ no _______
-rpg-
jlz
∂10-Feb-87 0246 RPG Registration
To: x3j13@SAIL.STANFORD.EDU
Don't forget to register for the March meeting. Registration closes
in a couple of weeks and right now there are only a handful registered.
-rpg-
∂10-Feb-87 2209 RPG Reminder About March Registration Procedure
To: x3j13@SAIL.STANFORD.EDU
X3J13 Meeting
3/16/87 - 3/19/87
Palo Alto, CA
The third meeting of X3J13 will be held from 1pm, Monday, March 16, 1987
until noon, Wednesday, March 18, 1987, at the Hyatt Rickeys (not to be
confused with the Hyatt Palo Alto across the street) in Palo Alto, CA.
Meetings on Monday and Tuesday will be in the Camino Ball Room C and on
Wednesday the meeting will be in the Executive Conference Room. Come
early, California is beautiful in March.
A block of rooms is available at the Hyatt Rickeys. The rate will be $92 a
night (plus tax). If you prefer, they have rooms available for non-smokers
(ahh, a room never touched by smoke). Please check the appropriate dates
and supply a credit card number if you wish to have the room guaranteed.
Check in time is 3:00pm. Check out time is 12:00 noon. I will be taking
reservations until 2/15/87. After that time please contact Hyatt Rickeys
directly at (800) 228-9000 for reservations and changes. Be sure to
mention ``Standards Committee X3J13'' or ``Lucid.'' Reservations must be
received by the hotel no later than 2/15/87 to receive the discounted rate.
Refreshments will be available during the morning and afternoon sessions.
Lunch has been arranged for Tuesday, March 17. If you have dietary
restrictions please complete the appropriate section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
Delta Airlines has agreed to give us a 35% discount to San Francisco. Call
Delta (or have your travel agent call) toll free at 1 (800) 241-6760 daily
8:30am thru 8:00pm EST. Please refer to file number A0732 when calling.
Tickets must be purchased 14 days in advance, there is no minimum stay, and
the maximum stay is 14 days. Please confirm early as there is limited
seating.
I will be happy to arrange a group dinner at the Thai Garden (a different
eating experience) the evening of March 16 with an extra cost. If you are
interested, please note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
| |
|X Hyatt Rickey |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rushhour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-0800. Hertz, Avis and National car rentals are
within 1 block.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@navajo.stanford.edu
(415) 329-8400
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid, Inc. mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Reservations: Mar 15: ___ Mar 16: ___ Mar 17: ___
___ single (1 person) ___ double (2 persons, 1 bed)
___ twin (2 persons, 2 beds) ___ triple (three persons, 2 beds)
The $92.00 room rate is only guaranteed for reservations received by
February 15.
Credit Card: ___ AMEX ___VISA ___ Mastercard ___Diners ___CB
Number: ___________________________________________ Exp ____________
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Dinner at Thai Garden 3/16: yes _______ no _______
-rpg-
jlz
∂13-Feb-87 1948 MATHIS@ADA20.ISI.EDU plans for Palo Alto and mailing
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87 19:46:39 PST
Date: 12 Feb 1987 11:35-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: plans for Palo Alto and mailing
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]12-Feb-87 11:35:35.MATHIS>
Today I put the following in the US mail to our physical mailing list.
Most of the documents referenced can also be had electronically. Two
items of particular interest follow -- the cover letter and the DRAFT
agenda (please send me any further detail you may have for a revised
agenda):
Doc. No.: X3J13/87-006
Date: 87-02-10
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
To X3J13 (Common Lisp) participants:
Enclosed are some of the documents relating to the upcoming
meeting in Palo Alto, CA on March 16-18, 1987. Most of you are on
the electronic mailing list and should have seen most of this
earlier. In particular hotel reservations are due about the time
you will probably receive this letter.
Dick Gabriel will be sending out information relative to the
objects proposal separately and directly [documents 87-002 and
87-003].
Notice that there is a revised version of Doc: 86-020 on Purposes
included with document 86-023. This includes some of the comments
that I saw on the net reproduced in a way that will hopefully
facilitate their consideration. If you have other comments or
changes that you may want to suggest at the meeting, please bring
about 50 copies for distribution there. I expect some action will
be taken on this document at the meeting.
Documents 86-017 and 86-018 are from the infamous lost boxes of
Dallas.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
Enclosures:
86-017 Excerpts from ISO/TC97/SC22 ad hoc report re Lisp
86-018 Papers from Symbolics re objects and flavors
86-019 from Mike Beckerle
86-020R included with 86-023
86-023 Comments on Purposes document 86-020
86-024 Comments on Lisp1/Lisp2 issues
87-000 Document Register for 1987
87-001 Document Register for 1986
87-004 Palo Alto Meeting Announcement
87-005 Draft Agenda for Palo Alto Meeting
SD-04 Meeting Schedule
Note: 87-002 and 87-003 being mailed separately.
Proposed Agenda X3J13/87-005
AGENDA -- Day 1
X3J13 (Common Lisp) Third Meeting, March 16-18, 1987
Hyatt Rickeys, Palo Alto, CA
1 Call to Order, March 16, 1:00pm
2 Opening Remarks and Introductions
3 Approval of Agenda (87-005)
4 Approval of Minutes of Sept 23-24 Meeting (Doc: 86-025)
5 Approval of Minutes of Dec 10-12 Meeting (Doc: 86-021)
6 Report on International Activities (Doc: 86-017)
7 Other Liaison Reports
8 Action on Goals and Objectives (Doc: 86-020R and 86-023)
9 Reports from Task Group Chairmen
10 Recess, 5:00pm
AGENDA -- Day 2
X3J13 (Common Lisp) Third Meeting, March 16-18, 1987
Hyatt Rickeys, Palo Alto, CA
11 Call to Order, March 17, 9:00am
12 Discussion of Objects Proposal (87-002 and 87-003)
13 LUNCH Second Day, 12:00-1:00pm
14 Continued Objects Discussion (87-002 and 87-003)
15 Recess, 5:00pm
AGENDA -- Day 3
X3J13 (Common Lisp) Third Meeting, March 16-18, 1987
Hyatt Rickeys, Palo Alto, CA
16 Call to Order, March 18, 9:00am
17 Additional Reports from Task Group Chairmen
18 Future Meeting Schedule (Doc: SD-04)
19 Review of Action Item Assignments
20 Adjournment, 12:00noon
∂27-Feb-87 1453 RPG X3 registration list 2/27/87
To: x3j13@SAIL.STANFORD.EDU
Below is the list of people I have heard from, hotel dates and
whether registration fees have been paid. Please check the
list and let me know if you disagree with any information about
yourself.
---jan---
Registration/Hotel List
02/27/87
Name Company Check In Check Out Paid
David Bartley TI 03/15/87 03/18/87 y
Michael Beckerle Gold Hill -0- -0- y
Eric Benson Lucid, Inc. -0- -0- -
Daniel Bobrow Xerox PARC -0- -0- y
Mary Boelk Johnson Controld, 03/15/87 03/18/87 y
Skona Brittain MSC -0- -0- -
Gary Brown Digital 03/15/87 03/18/87 y
Jerome Chailloux INRIA -0- -0- -
Christopher Dabrowski National Bureau of 03/16/87 03/18/87 y
Jeff Dalton AI Application 03/15/87 03/18/87 -
Linda DeMichiel Lucid, Inc. -0- -0- -
Patrick Dussud Texas Instruments 03/15/87 03/18/87 y
Susan Ennis AMOCO Production 03/15/87 03/18/87 y
Scott Fahlman CMU 03/14/87 03/18/87 y
John Foderaro Franz Inc. -0- -0- y
Dick Gabriel Lucid, Inc. -0- -0- -
Robert Giansiracusa Red Shark Software -0- -0- y
George Hadden Honeywell 03/16/87 03/18/87 y
Steve Haflich Franz Inc. -0- -0- y
Masayuki Ida Aoyama Gakuin 03/14/87 03/19/87 -
Kevin Layer Franz Inc. -0- -0- y
Bob Mathis DARPA 03/14/87 03/19/87 y
Ronald Ohlander USC/ISI -0- -0- y
Crispin Perdue SUN MicroSystems -0- -0- y
Bill Scherlis DARPA 03/15/87 03/18/87 -
David Slater Computer Sciences 03/15/87 03/17/87 y
S. Sridhar Tektronix, Inc. -0- -0- y
Guy Steele Thinking Machines, 03/15/87 03/18/87 y
Thomas Turba UNISYS 03/15/87 03/18/87 y
Ellen Waldrum TI 03/15/87 03/18/87 y
JonL White Lucid, Inc. -0- -0- -
Alexis Wieland MITRE 03/16/87 03/18/87 y
∂27-Feb-87 1513 ohlander@venera.isi.edu Re: X3 registration list 2/27/87
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Feb 87 15:13:46 PST
Posted-Date: Fri 27 Feb 87 15:14:12-PST
Received: by venera.isi.edu (5.54/5.51)
id AA03315; Fri, 27 Feb 87 15:14:12 PST
Date: Fri 27 Feb 87 15:14:12-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: X3 registration list 2/27/87
To: RPG@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 27-Feb-87 15:14:12.VENERA.ISI.EDU>
In-Reply-To: Message from "Dick Gabriel <RPG@SAIL.STANFORD.EDU>" of 27 Feb 87 1453 PST
Dick,
I will check in on the evening of the 17th of March and check out on the 18th
of March. I have made my room reservation independently.
Ron
-------
∂03-Mar-87 1251 berman@vaxa.isi.edu Re: Who's Where?
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 3 Mar 87 12:51:19 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA17152; Tue, 3 Mar 87 12:51:59 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8703032051.AA17152@vaxa.isi.edu>
Date: 3 Mar 1987 1251-PST (Tuesday)
To: berman@vaxa.isi.edu (Richard Berman)
Cc: X3J13@su-ai.arpa
Subject: Re: Who's Where?
In-Reply-To: My message of 2 Mar 1987 1332-PST (Monday).
<8703022132.AA05893@vaxa.isi.edu>
A few days ago I asked for the members of the X3J13 subgroup on validation to
please send me their current net address as part of a message (as opposed to
just having the mailer automatically generate one). So far Mike Beckerle and
John Foderaro have responded. Could Jon L. White and David Slater please
respond, as well as any others???
Thanks a bunch.
RB
∂03-Mar-87 1359 berman@vaxa.isi.edu Validation
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 3 Mar 87 13:59:30 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA17899; Tue, 3 Mar 87 13:59:42 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8703032159.AA17899@vaxa.isi.edu>
Date: 3 Mar 1987 1359-PST (Tuesday)
To: Marick@GSWD-VMS.ARPA
Cc: berman@vaxa.isi.edu, cl-validation@su-ai.arpa, X3J13@SU-AI.arpa
Subject: Validation
> I'm not going to respond to your message until you respond to mine.
> I just spent a weekend rewriting sequence function tests and,
> consequently, rewriting some sequence functions. I am more convinced
> than ever that a test suite should predate publication of a standard
> -- there's at least one other sequence function besides *ASSOC* that's
> underspecified. (Unfortunately, I didn't write it down, and I've
> forgotten which one, now.)
> Does the deafening silence mean consent?
Brian, let me know if this gets through. I have been responding to messages,
but sending them to marrick%cthulhu@gswd-vms.arpa has not worked.
I don't know that a test suite should *predate* standard publication, but it
should be part of that publication. In fact, when formally published it would
be a good idea to for the standard and the test-suite to cross reference each
other. That is, the each test should test a specific clause (or clauses?) of
the standard. The standard should also include forms which must evaluate in a
certain way where this is meaningful to the definition of some part of the
standard. In these cases the form would be part of the test suite.
HOWEVER....
I believe it is possible to have a useful test suite before the standard is
finalized and published. I am preparing a report now for the X3 meeting that
will outline some possible stages in the development of the test suite. Part
of our problem is that we are aiming at a moving target...
Best,
RB
∂07-Mar-87 1414 MATHIS@ADA20.ISI.EDU agenda update
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 7 Mar 87 14:14:45 PST
Date: 7 Mar 1987 14:15-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: agenda update
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 7-Mar-87 14:15:02.MATHIS>
Although I will not be making a revised agenda, on Monday, March
16, we will be having a report from Masayuki Ida on activities in
Japan, a report from Bob Balzer and Rich Berman on validation
developments, and I expect an initial report from the clean-up
committee which will probably continue on Wednesday morning. If
any of you have any last minute things to let me know about,
please send net mail before Saturday morning or contact me at the
hotel beginning Sunday. -- Bob
∂12-Mar-87 2210 RPG Final Attendee List
To: x3j13@SAIL.STANFORD.EDU
Here is the current list. See you Monday!
Registration/Hotel List
03/12/87
Name Company Check In Check Out Paid
John Allen The Lisp Co. -0- -0- y
David Bartley TI 03/15/87 03/18/87 y
Michael Beckerle Gold Hill -0- -0- y
Eric Benson Lucid, Inc. -0- -0- -
Richard Berman USC/ Information 03/16/87 03/19/87 y
Daniel Bobrow Xerox PARC -0- -0- y
Mary Boelk Johnson Controld, 03/15/87 03/18/87 y
Skona Brittain MSC -0- -0- y
Gary Brown Digital 03/15/87 03/18/87 y
Mike Cannon Hewlett-Packard -0- -0- y
Jerome Chailloux INRIA -0- -0- -
Chip Chapin Hewlet-Packard -0- -0- y
William Clinger Tektronics 03/16/87 03/18/87 y
Peter Coffee Aerospace Corp. 03/16/87 03/17/87 -
Pavel Curits Xerox AIS -0- -0- y
Christopher Dabrowski National Bureau of 03/16/87 03/18/87 y
Jeff Dalton AI Application 03/15/87 03/18/87 y
Andrew Daniels Xerox AIS -0- -0- y
Linda DeMichiel Lucid, Inc. -0- -0- -
Patrick Dussud Texas Instruments 03/15/87 03/18/87 y
Susan Ennis AMOCO Production 03/15/87 03/18/87 y
Scott Fahlman CMU 03/14/87 03/18/87 y
John Foderaro Franz Inc. -0- -0- y
Dick Gabriel Lucid, Inc. -0- -0- -
Robert Giansiracusa Red Shark Software -0- -0- y
George Hadden Honeywell 03/16/87 03/18/87 y
Steve Haflich Franz Inc. -0- -0- y
Jed Harris Intel -0- -0- y
Liz Heron IBM -0- -0- -
Carl Hewitt MIT 03/15/87 03/19/87 y
Masayuki Ida Aoyama Gakuin 03/14/87 03/19/87 -
Sonya Keene Symbolics, Inc. -0- -0- y
Jim Kempf Hewlett-Packard -0- -0- y
Gregor Kiczales Xerox PARC -0- -0- -
Kevin Layer Franz Inc. -0- -0- y
Jim Lin IBM -0- -0- -
Thom Linden IBM -0- -0- y
Barry Margolin Thinking Machines 03/15/87 03/19/87 -
Larry Masinter Xerox PARC -0- -0- y
Bob Mathis 03/14/87 03/19/87 y
David Matthews Hewlett Packard -0- -0- y
David Moon Symbolics, Inc. -0- -0- y
Ronald Ohlander USC/ISI 03/17/87 03/18/87 y
Bob Pellegrino Prime Computer, 03/15/87 03/19/87 y
Crispin Perdue SUN MicroSystems -0- -0- y
Kent Pitman Symbolics -0- -0- y
Bill Scherlis DARPA 03/15/87 03/18/87 -
David Slater Computer Sciences 03/15/87 03/17/87 y
Angela Sodan GMD -0- -0- y
S. Sridhar Tektronix, Inc. -0- -0- y
Guy Steele Thinking Machines, 03/15/87 03/18/87 y
Thomas Turba UNISYS 03/15/87 03/18/87 y
Ellen Waldrum TI 03/15/87 03/18/87 y
Mark Wegman IBM T.J. Watson -0- -0- y
Dan Weinreb Symbolics, Inc. -0- -0- y
JonL White Lucid, Inc. -0- -0- -
Alexis Wieland MITRE 03/16/87 03/18/87 y
∂13-Mar-87 0204 brown%bizet.DEC@decwrl.DEC.COM Technical Editor
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 13 Mar 87 02:04:49 PST
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA08145; Fri, 13 Mar 87 02:05:31 PST
Message-Id: <8703131005.AA08145@decwrl.dec.com>
Date: Friday, 13 Mar 1987 02:03:29-PST
From: brown%bizet.DEC@decwrl.DEC.COM
To: x3j13@SAIL.STANFORD.EDU
Subject: Technical Editor
The major conclusion arrived at from thinking about writing the
standard is that a technical editor is required. This person's
job would be to convert CLTL to an approved format, distribute
copies, and incorporate approved changes and new material - basically
to control the sources to the standard. This is clearly a full-time job.
DEC is willing to hire someone to do this job for, at least, the
first year. However, before hiring someone to do it, we need to know
if this is acceptable to the committee. Please consider this offer,
and let me know when we meet next week.
-Gary Brown
∂13-Mar-87 0852 RPG Writer
To: x3j13@SAIL.STANFORD.EDU
This is the kind of spirit of volunteerism that is required to
make our task succeed. I encourage others to note this offer and
consider what they themselves can do.
Because this committee as a whole has oversight over the writer,
I can see no objections whatever. Possibly we'll want to nominate
an editor or two to work with the writer and exercise immediate
direction?
-rpg-
∂18-Mar-87 1341 MATHIS@ADA20.ISI.EDU draft minutes Palo Alto meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 Mar 87 13:40:27 PST
Date: 18 Mar 1987 13:40-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: draft minutes Palo Alto meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU]18-Mar-87 13:40:53.MATHIS>
These are still quite rough, but Mary and I wanted to get them out fast.
Please send me your reactions and comments.
1:00pm ITEM 1 - Monday, March 16, 1987. Palo Alto meeting called to order.
ITEM 2 -Mathis - introductory remarks. New documents and missing Dallas
documents made available. Attendance book sent around. Introduction of
attendees.
ITEM 3 - March 16 agenda (X3J13/87-006) rearranged to bring forward points 8
and 9.
ITEM 4 - Sept 23-24 minutes (X3J13/86-025) sent out but had typos in names.
Corrections to other minutes will be noted in minutes of March 16-18
(X3J13/87-016)
ITEM 5 -Dec 10-12 minutes (X3J13/86-021) not yet available but should be
available by end of meeting.
ITEM 6
ISO ballot has been sent in, but the meeting is not planned until summer.
Anyone interested in joining the ISO working group is asked to contact Bob
Mathis. The size of the US delegation is planned to be about 6 people.
1:25pm ITEM 8 - Purposes of X3J13 Committee (X3J13/86-023 (revision of
X3J13/86-020))
1.
a. Guy Steele suggests changing "extensions" to "additional features".
Informal voice vote unanimously in favor.
b. Dave Moon concerned about phrase, "establishing normative practice".
Informal voice vote unanimously in favor of dropping phrase altogether.
"X3J13 is chartered to produce an American National Standard for Common
Lisp. It will codify existing practice and provide additional features to
facilitate portability of code among diverse implementations."
2.
a. Dave Matthews asks whether aesthetic criteria should exist at all.
Informal voice vote shows majority in favor of change in wording. Informal
voice vote unanimously in favor of Guy Steele's proposed wording change.
"The committee will begin with the language described in Common Lisp: The
Language by Guy L. Steele Jr. (Digital Press, 1984), which is the current
de facto standard for Common Lisp. Whenever there is a proposal for the
standard to differ from Common Lisp: The Language, the committee shall
weigh both future costs of adopting (or not adopting) a change and the
costs of conversion of existing code. Aesthetic considerations shall
also be weighed, but as subordinate criteria."
2:30pm - Comments by John McCarthy. Comments will be put into
future article for Lisp Pointers.
2:35pm - Break
ITEM 9 - Reports from Task Group Chairpeople
2:50pm - Bob Balzer, Rich Berman (ISI) - Validation Suite
Rich Berman described the current status of the test suite design. Format has
been designed and 550 tests converted into that format.
Bob Balzer described how ISI could run the test suite against a particular
implementation and produce a report of the results. The process is currently in
the Ad-hoc Stage for evaluation. Later stages will result in a managed test
suite. The effort is estimated to take 3.5 person-years to produce 25,000
normalized cases.
Discussion identified concern over the final use of the test suite (ie., for
implementors or for users), and over the extent of the effort devoted to
resolution of ambiguity in the language standard showed up by test cases.
The topic will be continued on Wednesday.
4:25pm - Professor Ida - Lisp Activities in Japan (X3J13/87-007)
4:40pm - Gary Brown (DEC)
Gary Brown has received permission from DEC to hire a technical writer to do
the actual creation of the standard, with copyright held by ANSI. The response
of the committee was enthusiastic applause.
4:50pm - Larry Masinter (Xerox) - Cleanup Committee
Current status (X3J13/87-010) describes status as of March, 1987 rather than
May, 1987. Distribution of language suggestions and changes through computer
networks was discussed, but not resolved. The discussion will be continued
Wednesday.
5:10pm - Meeting adjourned.
Tuesday, March 17, 1987. Palo Alto meeting called to order.
9:05am - Dan Bobrow, Opening Remarks
Common Lisp Object System Specification
1. Programmer Interface Concepts (X3J13/87-002)
2. Functions in the Programmer Interface (X3J13/87-002)
3. Meta Object Protocol (X3J13/87-003)
4. Glossary (X3J13/87-008)
5. Corrections and Amendments (X3J13/87-009)
9:10am - David Moon, "Common Lisp, Object System"
10:35am - Break
11:00am - Gregor Kiczales, "Programming with Meta-Objects"
1:05pm - Lunch Break
2:45pm - Dan Bobrow, "Meta Object Protocol"
4:00pm - Break
4:25pm - Questions and Answers on previous presentations
The discussion resulted in the decision to vote Wednesday morning on the X3J13
position on the work done to date on the Common Lisp Object System
Specification.
5:50pm - Meeting adjourned.
Wednesday, March 18, 1987. Palo Alto meeting called to order.
9:05am - Peter Coffee presented the wording of a motion which reflected the
discussion of Tuesday afternoon. The X3J13 committee unanimously voice voted
to have this moved. A majority voice vote determined that the motion would be
presented as three separate items with X3J13 document references.
On a motion by Peter Coffee, and a second by Mark Wegman, the
following formal motion was passed by unanimous voice vote.
Resolved by the National Technical Committee for Standardization of
Lisp (X3J13):
(1) The committee believes that object-oriented programming
will be incorporated as part of a future Common Lisp standard;
(2) The committee believes that Chapters 1 and 2 of the Common Lisp
Object System (CLOS) specification (collectively, X3J13 document 87-002)
captures the essentials of the future standard object facility.
The committee also looks forward to a refined version of CLOS
Chapter 3 (X3J13/87-003) that will similarly reflect the
essentials of a standard meta-object facility;
(3) The committee encourages experimentation with the object
system reflected in CLOS Chapters 1-3.
SUBCOMMITTEE REPORTS
9:30am - Jon L. White - Iteration Subcommittee
JonL described the work done to date of the committee on identifying several
iteration paradymes, and will create a preliminary document for distribution.
9:35am - Kent Pitman - Macros; Errors and Conditions Subcommittee
Kent described the continuing work on xx (X3J13/xxx), and felt that the work
was beginning to converge. It is expected that the converged design will
be presented at the next meeting.
9:40am - Rich Berman - Validation and Conformance Subcommittee
Rich summarized the presentation which he gave on Monday.
9:45am - Gary Brown - Presentation of Standard Subcommittee
Gary reiterated that the standard will be controlled by ANSI rules. The actual
creation of the document will be done by a technical writer who will be hired
by DEC. The text editing system used for this document will be TEX.
An editorial subcommmittee has been formed. The current volunteers are
Pavel, Margolin, Slater, Fahlman, Weinreb, Pitman, Linden, Ennis, and Ida.
Gary suggested that a formal definition of some parts of Common Lisp would
be valuable. The response of the committee indicated that further discussion
of this issue was needed.
10:05am - Dan Bobrow - Objects Subcommittee
Dan thanked the committee for their feedback on the CLOS design.
10:07am - Dick Gabriel - Lisp 1/Lisp 2 Subcommittee
The topic has been temporarily quiescent, due to subcommittee members
being involved elsewhere.
10:10am - Steve Haflich - Compiler Specification Subcommittee.
A large amount of work has been done on a specification document. The subcommittee is intending to stop and look at
the more global issues of what their task encompasses and how they should
approach the problems.
10:20am - Bob Mathis - NEXT MEETING PLANNING
The consensus of the committee was to have a two full day meeting on
Tuesday (10am - 6pm) and Wednesday (9am - 4pm), June 30th and July 1st.
Subcommittees were encouraged to meet on Monday afternoon.
10:35am - Break
11:00am - Bob Mathis - FUTURE MEETING PLANNING
Susan Ennis has agreed to act as a clearinghouse for information on
possible meeting sites and times.
ll:00am - Larry Masinter - Cleanup Subcommittee
Bob Mathis will create a message to the Common Lisp mailing list describing the
standardization process. He will reiterate that the X3J13 committee is open,
but that it is only within X3J13 that the technical discussions will occur.
The discussion considered the ways in which the cleanup proposals would be
presented to the committee for final voting. When proposals are presented
in the future, Larry will identify those which are potentially controversial.
Proposals will be presented to the committee in advance of the meeting.
After a proposal has been accepted, the editorial committee will give
direction to the technical writer for incorporation into the standard.
12:00 noon - Final Meeting Adjournment
∂18-Mar-87 1342 MATHIS@ADA20.ISI.EDU meeting documents
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 Mar 87 13:42:25 PST
Date: 18 Mar 1987 13:43-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: meeting documents
Subject: [MATHIS@ADA20.ISI.EDU: minutes first meeting]
Subject: [MATHIS@ADA20.ISI.EDU: document register]
Subject: [MATHIS@ADA20.ISI.EDU: Purposes document]
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]18-Mar-87 13:43:03.MATHIS>
These messages were printed and distributed Wednesday morning at the meeting.
Begin forwarded messages
Received: By ADA20.ISI.EDU via direct-append with Hermes; 17 Mar 87 23:04:40-PST
Date: 17 Mar 1987 23:04-PST
From: MATHIS@ADA20.ISI.EDU
To: edsel!jlz@NAVAJO.STANFORD.EDU
Cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: minutes first meeting
Message-ID: <[ADA20.ISI.EDU]17-Mar-87 23:04:37.MATHIS>
Sender: MATHIS@ADA20.ISI.EDU
DRAFT Minutes X3J13 Committee Meeting
Dates: September 23-24, 1986
Location: CBEMA Headquarters, Washington, DC
Chair: Bob Mathis (acting)
Secretary: Steve Haflich (acting)
Hour of opening: September 23, 1986, 9:00 AM
Hour of adjournment: September 24, 1986, 3:00 PM
List of Voting members: Attached
Approved Agenda: Attached (86-0016)
Approval of previous minutes: None (this was first meeting)
Register of Documents: Attached
Motions seconded and not withdrawn:
Future meeting schedule:
The next meeting is scheduled for Decmeber 10-12, 1986, in
Dallas, TX. Ellen Waldrum will make the arrangements.
List of action items assigned to committee members:
Mathis will contact DEC Press about using the Steele book as a
basis for the standard
The meeting was called to order at 10:00 AM, September 23, 1986.
The agenda, X3J13/86-001, was approved without objection.
Catherine Kachuric, Director of the X3 Secretariat presented a
tutorial on the organization and operation of X3. Most of the
details are codified in the X3/SD-2 operating document which was
distributed at the meeting.
Mathis led a discussion of meeting procedures:
1. by consensus it was decided there will be no smoking in
X3J13 meeting rooms;
2. each meeting will focus on one or more technical issues
with prepared presentations, it is necessary that the
membership be well prepared technically in advance of
meetings so that final discussions and voting can be
facilitated during scarce meeting time;
3. Gabriel will set up a new mailing list which will function
as a subset of the existing COMMON-LISP@SAIL.STANFORD.EDU,
and therefore nothing should be sent to both lists. Also,
anything with a time limit for action should be sent to
X3J13, not COMMON-LISP, as not all members will read the
latter in a timely fashion. Addresses are:
X3J13@SAIL.STANFORD.EDU
X3J13-REQUEST@SAIL.STANFORD.EDU
RPG@SAIL.STANFORD.EDU
4. Mathis can be reached at MATHIS@B.ISI.EDU. Since only a
few members lack internet access, the committee will
consider using electronic mail for discussion. Mathis will
attempt to arrange network access for members in need.
All written X3 subcommittee communications are distributed to
everybody and are filed as part of the official records. There
was discussion whether this would apply to electronic mail to
x3j13@Stanford. Some people feel that network comments are made
informally and are similar to oral communications; therefore,
they should not be available as a written record. There was a
conflicting desire that the archives be publically available
(e.g. via FTP) since this has proven useful with
COMMON-LISP@STANFORD. It was provisionally agreed that the
archives would be maintained, but for now they would not be
publically accessible.
There was further discussion of how to bypass one of the
shortcomings of electronic communication -- the volume of the
archive makes it a poor reference source and decisions can get
lost. Therefore, it was oproposed that when discussion on a point
dies down there should be a summarization of discussion placed in
a small, more readable ledger and this document would be recorded
and distributed by X3J13.
Mathis requested a committee to further consider the use of
network communication: Mathis, Pitman, Fahlman, Rosenking, and
Haflich.
Mathis led a discussion of the project proposal (subsequently
given the number X3J13/SD-2.
The title is "Common Lisp" rather than "Lisp" although this could
be changed with little effort. The scope of the committee is one
of the items that will have to be decised. There was general
agreement that we are standardizing Common Lisp, not all Lisp for
all time. Gabriel informed the meeting that McCarthy objects to
our using plain "Lisp." It is intended that X3J13 will subsume
the less formal technical committee formed after the December
1985 Boston meeting.
Several parties were interested in the relationship with Digital
Press over rights to use the Steele book. Considerable discussion
occurred with the eventual result that Mathis would work directly
with Digital Press to make appropriate arrangements.
After a lunch recess, the meeting reconvened at 2:30 PM.
Dan Bobrow made an introductory presentation on Common Loops.
[The preliminary document for this presentation was 86-004 and
the slides from it were distributed as 86-006.] Discussion of
Common loops followed, particularly regarding the nature of a
specification and the best process for arriving at one. There
will be a small meeting at OOPSLA on the current proposal and a
new draft will follow.
Mathis reported that Mary van Deusen has volunteered to produce
an unedited Lisp newsletter in the same manner that she produced
the original Ada newsletter. It was also noted that Gabriel and
Steele will also be editing a professional refereed quarterly for
Kliewer. Both publications felt there was no conflict.
There was some technical discusison of removing function-value
cell separation from Common Lisp. Discussion was started
explicitly to serve a s a trial vehicle to focus on the extent to
which the committee would be willing to make changes that would
disrupt the installed base. This discussion will be continued at
future meetings.
A subcommittee, chaired by Ennis, was formed to develop a draft
document for the proposed scope and purposes of X3J13. They met
over dinner and during the evening. Their draft [86-005] was
presented the next morning.
The meeting was recessed on September 23, 1986 at 5:15 PM.
The meeting was resumed on September 24, 1986 at 9:00 AM.
Steele led a discussion of his two documents relating to SD-1
[Common Lisp: The Language] which were first distributed at the
December 1985 Common Lisp community meeting [86-002 and 86-003].
The intention is that once a version of 86-002 is approved, all
references to SD-1 will mean the Steele book "as corrected."
There was considerable discussion on the various topics, but no
specific issues were resolved at the meeting.
After a lunch recess, the meeting reconvened at 1:00 PM.
Mathis led a discussion of a potential meeting schedule. Several
offers were made including MCC Austin, MIT Boston, and TI Dallas.
After a discussion of optimizing meeting location, timing,
length, etc., it was decisded to meet in Dallas, December 10-12.
There was also sentiment expressed for the next meeting to be in
Palo Alto and the one after that in Boston.
Mathis asked the following to serve as an agenda committee for
the next meeting: Mathis, Fahlman, Gabriel, Purdue, Ennis,
Steele, and Scherlis. Furthermore, these items were suggested as
natural for the next agenda:
-- studying the possibility of merging symbol function cells
in Common Lisp with value cells (like Scheme),
-- Pitman will presnet the error system proposal,
-- further consideration of the current scoping and
declaration issues (the intention is to devise a proposal
over the network to be disteributed before the meeting),
-- the ongoing negotiations with ISO.
The meeting was adjourned on September 24, 1986 at 3:00 PM.
Respectfully Submitted,
Steve Haflich and Bob Mathis
--------------------
Received: By ADA20.ISI.EDU via direct-append with Hermes; 17 Mar 87 23:10:04-PST
Date: 17 Mar 1987 23:10-PST
From: MATHIS@ADA20.ISI.EDU
To: edsel!jlz@NAVAJO.STANFORD.EDU
Cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: document register
Message-ID: <[ADA20.ISI.EDU]17-Mar-87 23:10:01.MATHIS>
Sender: MATHIS@ADA20.ISI.EDU
Standing Documents (date of latest revision)
SD-01 Common Lisp: The Language, Guy L. Steele Jr., Digital
Press, 1984.
SD-02 Common Lisp Project Prosal to SPARC (86.02.18)
SD-03 Current Membership List of X3J13 (in preparation)
SD-04 Meeting Schedule (87.02.10)
SD-05 Purposes of X3J13 Committee (87.03.16)
This year's Documents
87-000 Document Register for 1987 (87.03.17)
87-001 Document Register for 1986 (87.02.10)
87-002 Objects Chapter 1 & 2
87-003 Objects Chapter 3
87-004 Palo Alto Meeting Announcement
87-005 Draft Agenda for Palo Alto Meeting
87-006 Cover letter dated 87.02.10 which included 86-017,
86-018, 86-019, 86-020R, 86-023, 86-024, 87-000, 87-001,
87-004, 87-005, SD-04.
87-007 A Progress Report on the Common Lisp Related Activities
in Japan by Masayuki Ida.
87-008 Common Lisp Object System Specification Glossary
87-009 Common Lisp Object System Specification Corrections and
Amendments to the Document
87-010 Cleanup Committee Report
87-011 "Encapsulation and Inheritance in Object-Oriented
Programming Languages" by Alan Snyder, OOPSLA, 1986.
87-012 Slides from David Moon's presentation 87.03.17
87-013 Slides from Gregor Kiczales's presentation 87.03.17
87-014 Slides from Danny Bobrow's presentation 87.03.17
87-015 Further reactions to 86-019
87-016 Draft Minutes Palo Alto meeting 87.03.16-18
87-017 Cover letter dated 87.03.29 which included
87-018
87-019
Next year's Documents
88-000 Document Register for 1988
88-001 Document Register for 1987
88-002
--------------------
Received: By ADA20.ISI.EDU via direct-append with Hermes; 17 Mar 87 23:14:39-PST
Date: 17 Mar 1987 23:14-PST
From: MATHIS@ADA20.ISI.EDU
To: edsel!jlz@NAVAJO.STANFORD.EDU
Cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: Purposes document
Message-ID: <[ADA20.ISI.EDU]17-Mar-87 23:14:37.MATHIS>
Sender: MATHIS@ADA20.ISI.EDU
X3J13/SD-05 Purposes of X3J13 Committee (87.03.16)
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice and provide
additional features to facilitate portability of code among
diverse implementations.
2. The committee will begin with the language described in Common
Lisp: The Language by Guy L. Steele Jr. (Digital Press, 1984),
which is the current de facto standard for Common Lisp. Whenever
there is a proposal for the standard to differ from Common Lisp:
The Language, the committee shall weigh both future costs of
adopting (or not adopting) a change and costs of conversion of
existing code. Aesthetic considerations shall also be weighed,
but as subordinate criteria.
3. The committee will address at least the following topics in
the course of producing the standard, in each case either
incorporating specific features or explaining why no action was
taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in Common Lisp: The Language
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in Common Lisp: The Language
that require resolution. Topics (d) and (e) are not addressed by
Common Lisp: The Language, but appear to be well-understood and
ready for standardization. Topics (f)-(i) concern areas where
standardization is desirable but not crucial to production of a
standard. Topic (j) is an area of current controversy within the
Lisp community. Other topics may be considered if specific
proposals are received.
4. The committee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
--------------------
End forwarded messages
∂20-Mar-87 1345 primerd!doug@enx.prime.pdn Windows and Graphics Subcommittee
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Mar 87 13:45:07 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA27326@EDDIE.MIT.EDU>; Fri, 20 Mar 87 16:45:27 EST
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA00379; Fri, 20 Mar 87 15:42:59 EST
Message-Id: <8703202042.AA00379@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 20 Mar 87 14:41:51 EST
Subject: Windows and Graphics Subcommittee
To: x3j13@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 20 Mar 87 14:41:51 EST
I would like to make known that there is a mailing list for the
windows and graphics subgroup. To subscribe you can send mail
to me as dougr@eddie.mit.edu. The mailing list is
x3j13-windows@primerd.prime.com@eddie.mit.edu
Cheers,
Doug Rand
∂23-Mar-87 1130 berman@vaxa.isi.edu Gary Brown...
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 23 Mar 87 11:29:08 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA05051; Mon, 23 Mar 87 11:30:48 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8703231930.AA05051@vaxa.isi.edu>
Date: 23 Mar 1987 1130-PST (Monday)
To: X3J13@SAIL
Cc:
Subject: Gary Brown...
I tried to send you mail at brown%bizet.DEC@decwrl.dec.com, but no luck, says
host not known. You got another address??
RB
∂20-Apr-87 0042 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the Kanji feature of Common Lisp
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Apr 87 00:42:15 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa07982; 20 Apr 87 3:41 EDT
Received: from utokyo-relay by RELAY.CS.NET id ab14315; 20 Apr 87 3:34 AST
Received: from tansei.u-tokyo.junet by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA08435; Mon, 20 Apr 87 16:42:07 jst
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA14916; Mon, 20 Apr 87 16:33:09+0900
Date: Mon, 20 Apr 87 16:33:09+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8704200733.AA14916@tansei.u-tokyo.junet>
To: ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU,
x3j13@SAIL.STANFORD.EDU
Subject: On the Kanji feature of Common Lisp
Dear Bob Mathis,
Please suggest your idea on the contents of this mail.
Thank you.
Masayuki
--------------------------------------------------------
On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
We concluded that
1) we want to propose our specification to ANSI X3J13.
The specification is not so restrictive.
2) Prior to do so, One of the author, namely ida, will send
the whole contents to common-lisp@sail.stanford to get
reactions of the US colleagues.
3) The proposed date of submission to CL bboard is
on the week of May 11th.
4) We are ready to send a person to the next meeting
to explain our proposal.
5) The reactions on the CL bboard will be gathered, and will
be transfered to WG members as quick as possible.
(several of them have E-mail links to ida.)
We will try to discuss on the issue by E-mails as possible as we can.
(we have no ethernet-like link to USA, so we cannot reply immediately.)
we finished the first draft of the english version.
It was mainly translated by the person of Nippon Symbolics.
(Thanks Mr.Shiota.)
The size is 12 pages long in letter sized papers.
We will revise up and send it.
Masayuki Ida
∂20-Apr-87 2253 dcm%hpfclp@hplabs.HP.COM Fall X3J13 meeting
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 22:53:25 PDT
Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Mon, 20 Apr 87 21:53:46 pst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Mon, 20 Apr 87 23:52:41 mst
Received: by hpfcdcm.HP.COM; Mon, 20 Apr 87 22:53:41 mst
Date: Mon, 20 Apr 87 22:53:41 mst
From: Dave Matthews <dcm%hpfclp@hplabs.HP.COM>
Return-Path: <dcm@hpfcdcm>
Message-Id: <8704210553.AA03000@hpfcdcm.HP.COM>
To: +cl/x3j13@hplabs.HP.COM, x3j13@sail.stanford.edu
Subject: Fall X3J13 meeting
It probably seems a little early to start thinking about our fall meeting,
but I thought I would take an informal survey to help make the necessary
arrangements so we can confirm them at the summer meeting.
At the last X3J13 meeting, Susan Ennis volunteered to coordinate the
meeting schedule and I volunteered to host the fall meeting of X3J13
in colorful Colorado. We recently talked about the schedule for the
fall meeting and there seem to be a number of conferences that
time of year. We would like to pick a time convenient to as many
members as possible so I would like to conduct a survey.
Three months after the next meeting in late June would be late September
so I would nominally suggest September 28-30. Please fill out the
following table of available dates, listing the conflict if you believe
that others on the committee may have it also, such as OOPSLA.
Dates: MTWTF(y/n) Conflict?
------------- ----- ---------------------
Sep 21-Sep 25
Sep 28-Oct 2 yyyyy Example
Oct 5-Oct 9
Oct 12-Oct 16
Oct 19-Oct 23
Hopefully this range of dates will be sufficient for choosing 3 days.
I'll use this information to make preliminary arrangements and have a
proposal ready at the next meeting. Please return this by May 29.
Thanks,
Dave Matthews
dcm%hpfclp@hplabs.hp.com
∂21-Apr-87 0821 RWK@YUKON.SCRC.Symbolics.COM On the Kanji feature of Common Lisp
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 08:21:20 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 195935; Tue 21-Apr-87 07:24:34 EDT
Date: Tue, 21 Apr 87 07:24 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: On the Kanji feature of Common Lisp
To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
cc: ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU,
x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8704200733.AA14916@tansei.u-tokyo.junet>
Message-ID: <870421072404.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Mon, 20 Apr 87 16:33:09+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
We concluded that
1) we want to propose our specification to ANSI X3J13.
The specification is not so restrictive.
Professor Ida:
I believe it doesn't do it justice to describe this extension as a
"kanji extension". I have not yet seen an English translation of the
proposal, but from what I have seen of it, it appears to address much
wider concerns. I believe the concerns are quite relevant to any
implementation which deals with extended character-sets, or even which
try to make use of Common-Lisp's unfortunate "font" features.
From what I've been able to make of the proposal, it seems you are
on the right track, and I eagerly await your proposal.
∂23-Apr-87 0106 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the character-set extension of Common Lisp
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Apr 87 01:06:01 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa13110; 23 Apr 87 4:02 EDT
Received: from utokyo-relay by RELAY.CS.NET id ab04744; 23 Apr 87 3:54 AST
Received: from tansei.u-tokyo.junet by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA27855; Thu, 23 Apr 87 16:04:19 jst
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA04391; Thu, 23 Apr 87 15:55:22+0900
Date: Thu, 23 Apr 87 15:55:22+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8704230655.AA04391@tansei.u-tokyo.junet>
To: RWK@SCRC-YUKON.ARPA, ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU,
x3j13@SAIL.STANFORD.EDU
Subject: On the character-set extension of Common Lisp
>Date: Tue, 21 Apr 87 07:24 EDT
>From: "Robert W. Kerns" <RWK@scrc-yukon.arpa>
>Subject: On the Kanji feature of Common Lisp
>To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
>
> Date: Mon, 20 Apr 87 16:33:09+0900
> From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
> On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
> Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
>
>Professor Ida:
>
>I believe it doesn't do it justice to describe this extension as a
>"kanji extension". I have not yet seen an English translation of the
>proposal, but from what I have seen of it, it appears to address much
>wider concerns. I believe the concerns are quite relevant to any
>implementation which deals with extended character-sets, or even which
>try to make use of Common-Lisp's unfortunate "font" features.
>
>>From what I've been able to make of the proposal, it seems you are
>on the right track, and I eagerly await your proposal.
>
>
Dear RWK,
you are right. I should have not described our conclusion on the extended
character-set manipulation as "kanji extension".
Though I myself told the WG on the Apr 17 meeting to update our document
to use the word "multi-byte character"
instead of "japanese character" or "kanji",
I myself missed to refer it as a "kanji" extension in my last mail.
Thank you
Masayuki Ida
∂15-May-87 0436 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Next Meeting
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 15 May 87 04:36:33 PDT
Received: from HAL.CAD.MCC.COM by MCC.COM with TCP; Fri 15 May 87 06:35:50-CDT
Date: Fri, 15 May 87 06:34 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Next Meeting
To: X3J13%sail.stanford.edu@MCC.COM
cc: Loeffler@MCC.COM
Message-ID: <870515063459.3.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
I have not seen any activity on this mailing list since the 23th of
April. What are the arrangements for the next meeting?
-- David D. Loeffler
∂31-May-87 0903 MATHIS@ADA20.ISI.EDU
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:03:19 PDT
Date: 31 May 1987 09:02-PDT
Sender: MATHIS@ADA20.ISI.EDU
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: RWS@ZERMATT.LCS.MIT.EDU
Message-ID: <[ADA20.ISI.EDU]31-May-87 09:02:47.MATHIS>
A few words about the upcoming X3J13 meeting:
The meeting is being hosted by Goldhill Computers. Maria Santos
is making the arrangements. Their phone number is (617)
492-2071. They are reserving some rooms at the Cambridge Marriott
at a rate of $115 (plus tax) per night (insead of the more usual
$135). There will be some fee for refreshments and maybe a lunch.
I don't know what it will be, but at the last two meetings we
paid $25 or $50. The meeting will be on Tuesday June 30 and
Wednesday July 1. We will be meeting from about 9am to 5pm each
day. There may be some subcommittee meetings on Monday. They are
hoping to arrange some meeting rooms at MIT, but I don't know the
specifics yet. Hope you can all make it.
I was thinking about the following agenda:
Tuesday morning -- clean-up committee
Tuesday afternoon -- X windows presentation, Japanese
characters presentation, administrative work of committee,
reports from various subcommittees and liaisons
Wednesday morning -- continuation of subcommittee reports
and other business, clean-up committee
Wednesday afternoon -- clean-up committee
We picked Tuesday and Wednesday for the main meeting so we could
use Monday for subcommittees if needed.
The X windows presentation will be by Robert Scheifler. We are
not looking at this for incorporation into the Common Lisp
standard, but as an important and relevant related application.
CLX is a proposed interface to the X Version 11 Window System
Protocol. It is intended as fairly low-level veneer, to hide
mundane details such as data encodings, network I/O, and even the
existance of an explicit inter-process communication channel.
The intent is to provide direct access to features of the
protocol, but with an effective Lisp orientation, and with
consideration given to convenience of use. A goal was to permit
efficient implementations on both conventional and Lisp-specific
architectures, and to provide reasonable semantics in both
single-process and multi-process environments. The expectation
and desire is that this X-specific interface will be wrapped by
more generic and higher-level windowing and graphics interfaces,
suitable for general application programming. However, we did
not wish to preclude an X-specific, object-oriented system built
directly on this interface. A public implementation of this
interface is underway, to serve as a mechanism for evaluating the
interface.
I am sending five relatively long messages which I recieved from
Scheifler which give the protocol and the Lisp code.
The Japanese characters proposal was sent to the general Common
Lisp mailing list. I am retransmitting it for your reference.
The cleanup committee has been hard at work and they will shortly
be sending their documents. So read what I'm sending now and save
it some place because more is coming.
-- Bob
∂31-May-87 0915 MATHIS@ADA20.ISI.EDU A multi-byte character extension proposal
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:14:47 PDT
Return-Path: <@USC-ECLB.ARPA,@SAIL.STANFORD.EDU,@RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET>
Date: Mon, 18 May 87 14:06:46+0900
From: Masayuki Ida <a37078%tansei.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8705180506.AA06726@tansei.cc.u-tokyo.junet>
To: common-lisp@SAIL.STANFORD.EDU, ida%tansei.u-tokyo.junet@RELAY.CS.NET
Subject: A multi-byte character extension proposal
ReSent-To: x3j13@SAIL.STANFORD.EDU
ReSent-From: MATHIS at ADA20.ISI.EDU
ReSent-Date: 31 May 1987
Date: Mon, 18 May 87 09:44:19 JST
From: moto@XXX.XXX.junet (MOTOYOSHI)
To: ida@tansei.cc.u-tokyo.junet
Subject: Kanji Proposal
-------------------- Beginning of text --------------------
@Comment[-*- Mode: Text -*-]
@heading[Digest]
@heading[1. Hierarcy of characters and strings]
Let the value of char-code-limit be large enough to include all
characters.
char > string-char >= internal-string-char > standard-char
string >= internal-thin-string > simple-internal-thin-string
simple-string >= simple-internal-thin-string
string = (or internal-thin-string (vector string-char))
Type internal-thin-string and (vector string-char) are
disjoint or identical.
simple-string = (or simple-internal-thin-string
(simple-array string-char (*)))
Type simple-internal-thin-string and (simple-array
string-char (*)) are disjoint or identical.
notes: A > B means B is a subtype of A,
A >= B means B is a subtype of A or B is equal to A.
@Heading[2. Print width]
Only standard characters are required to have fix-pitched
print width. Use the newly introdued function 'write-width'
to know the print width of an expression.
@Heading[3. Functions]
Functions dealing with strings should work as before,
expect ones which change the contents of internal-thin-string
to non internal-thin-char's.
Functions producing strings should create (vector
string-char), not internal-thin-string, unless they were
explicitly specified.
Funtions comaring strings should copare them elementwise.
Therefore it is possible that a (vector string-char) is equal
to an internal-thin-string.
@newpage
@Heading[1. A proposal for embedding multi-byte characters]
The Kanji Working Group (KWG) examined implementation of facilities for
multi-byte character to Common Lisp. This report is the result of many
discussions of many proposals. Of course, this report doesn't satisfy
all proposals, but it is very close.
In order to decide on a final proposal, we chose essential and
desirable characteristics of a working multi-byte character system.
Chapter 2 describes these characteristics in some detail.
Chapter 3 describes additional features to Common Lisp which will be useful
not just for multi-byte character, but also for many other kinds of character sets.
This chapter describes internal data structures. If this proposal is
accepted in Common Lisp, it will be easy for countries to add original mechanisms.
Chapters 4 describes proposed changes to @I[Common Lisp -- The Language]
(CLtL).
@Heading[2. Additional features for embedding multi-byte characters.]
This chapter describes design principles which can be used to design
multi-byte character language extensions to Common Lisp.
There are many programming languages which can multi-byte characters.
Most of them can use multi-byte character as string character data
but not as variables or function names.
It is necessary for programming languages like Lisp that use symbolic data
to be able to process not only single-byte characters but also multi-byte characters.
That is, it should be possible to use multi-byte characters in character string and
symbols, and it must be possible to store both kinds of characters in them.
Treating multi-byte characters just like other alpha-numeric characters
means that multi-byte character must be treated as a single character object.
Many of the present implementations of Lisp treat multi-byte character as
pairs of bytes. Alternatively, they use a different data type which
doesn't permit multi-byte character to be mixed with standard characters.
Such systems are not useful for user.
Thus, the basic design principles for embedding multi-byte character to Common Lisp are:
@Begin[Itemize]
Multi-byte character should be treated like single-byte character, that is,
a multi-byte character is one character object.
@End[Itemize]
@Begin[Itemize]
A program which was coded without explicit attention for multi-byte character should
handle multi-byte character data as is.
@End[Itemize]
These principles provide sufficient functionality, but we can't ignore
efficiency. So we considered the next principle:
@Begin[Itemize]
The performance of the system in terms of CPU and memory
utilization should not be consideraly affected in programs which do not use multi-byte
characters.
@End[Itemize]
This principle is contradictory to other principles, but this can't be
ignored when we consider the users of actual systems, so we have to
compromise. We think that following methods will satisfy both of these
requirements.
@Heading[3. Common parts which we implement.]
This chapter describes the implementation of multiple character sets in Common Lisp.
To treat multi-byte characters like single-byte characters, the multi-byte character must be
included in the set of possible character codes.
We consider the following implementation methods.
@Begin[Itemize]
Add multi-byte characters by setting the variable char-code-limit to a large number.
@End[Itemize]
In this case, the single-byte character set and the multi-byte character
set must be ordered into a single sequence of character codes. This means multi-byte
character set must not overlap with the single-byte character set. This method could
be satisfied within most implementations with ease.
If we use this method, it is possible to use multi-byte characters with
fonts in Common Lisp, and operations that work for single-byte
character will also work for multi-byte character without any change.
This implementation method has problems with efficiency.
In the case that the value of character code is greater than size of 1 byte
(multi-byte characters are in this category), memory utilization is
affected. A string containing only one single-byte character is 2 bytes long.
The same problem would also occur with symbol p-names. If we can solve the problem
for strings, we can solve other problems, so we will start by considering only strings.
To avoid this memory utilization problem, it is possible to optimize and
make single-byte character strings by packing internally. In other words,
to have two kinds of data types and not show it to user. There is only one type of
data from the viewpoint of users, which means that every function which uses strings
will continue to work as defined.
This can be implemented in almost everywhere without so many costs. The only
problem occurs when a function attempts to put a multi-byte character into an optimized
and packed sigle-byte-only string. To work according to the definition, the implementation
must unpack the original packed string. This presents an implementation inefficiency which
the user may find undesirable.
One solution would be to
@Begin[Itemize]
Generate errors for operations that try to use multi-byte characters into
single-byte string and presenting two string datatypes to users.
@End[Itemize]
We propose this latter implementation. Common lisp should have 2 string
types to treat multi-byte characters efficiently. The first of these is
@b[ε1stringε0], which stores any character of type @B[ε1string-charε0], i.e.,
whose @I[ε2bitsε0] and @I[ε2fontε0] are both zero. The type of string is
@B[ε1internal-thin-stringε0] which is the optimized character string.
@B[ε1internal-thin-charε0] is a subtype of @B[ε1characterε0] and can be inserted into string
@B[ε1internal-thin-stringε0]. The predicate which tests for this type of character is
@B[ε1internal-thin-char-pε0].
The type @B[ε1internal-thin-charε0] is a subtype of @B[ε1string-charε0], and is a
supertype of @B[ε1standard-charε0].
The data type hierarchy for @B[ε1characterε0] and @B[ε1stringε0] is shown in figure 1.
@b[ε1Internal-thin-charε0] and @b[ε1string-charε0] may be equal as it is possible that situations
may arise where both sets describe the same character-set.
This is equivalent to the type of system that has only one type of character from the
viewpoint of the user as discussed in the previous chapter. This proposal permits both
kinds of implementations.
@newpage
@Begin[Verbatim]
character
|
string-char
|
internal-thin-char
|
standard-char
@Center[Fig-1.a Structure of character type]
string
|
-----------------------------------
| | |
| simple-string |
| | |
internal-thin-string | (vector string-char)
| | |
-----------------------------------
| |
| |
simple-internal-thin-string (simple-array string-char (*))
@Center[Fig-1.b Structure of string type]
@End[Verbatim]
To compare @B[ε1stringε0] characters with @B[ε1internal-thin-stringε0] characters, it is
necessary to convert both to the @B[ε1string-charε0] format. This means that
the same character is the same object regardless of whether it is found
in an @B[ε1internal-thin-stringε0] or a normal @B[ε1stringε0].
Next we must discuss character input. The proposal does not discuss what is stored
in files, nor what happens between the Lispimplementation and a terminal.
Each system will implement this in itsown way. Instead, let us discuss the data
as passed to lisp programs. We think that treating all input data as @B[ε1stringε0]
is the safest possible course. Since a symbol's p-name string should not be modified,
it can be optimized.
This may cause performance problems for programs which use only
single-byte characters. The variable @B[ε1*read-default-string-type*ε0] is
provided for these programs. When its value is @B[ε1internal-thin-stringε0], the system
expects single-byte characters only. so the system will return input data
in the form of @B[ε1internal-thin-stringε0]. Though it is possible that the system may
choose to ignore this variable.
@newpage
@Heading[4 Proposed changes to CLtL to support multiple character sets.]
In this section, we list proposed modifications to CLtL. Chapters 13,
14 and 18 of CLtL are concerned very greatly with multi-byte character, so we specify
modifications to these chapters by making a list of all constants,
functions and variables. For other chapters we specify only additional
and modifying parts. Those portions which are not mentioned are
unchanged.
@b(2 Data Types)
@b(2.5.2 Strings)
@begin(equation)
"a string is a specialized vector .... type string-char"
↓
"a string is a specialized vector .... type string-char or @B[internal-thin-char]"
@end(equation)
@b(2.15 Overlap,Inclusion and Disjointness of Types)
a description of type string-char is changed to :
Type standard-char is a subtype of @B[internal-thin-char].
@B[internal-thin-char] is a subtype of string-char. string-char is a
subtype of character.
and add the following :
Type @B[internal-thin-string] is a subtype of vector because @B[internal-thin-string] means
(vector internal-thin-char).
a description of type string is changed to :
Type string is a subtype of vector because string means (or
(vector string-char) internal-thin-string). Type (vector
string-char) and @B[internal-thin-string] are disjoint or equality.
a description of type simple-vector,simple-string ... is changed to :
Type simple-vector,simple-string and simple-bit-vector are disjoint subtype of
simple-array because each one means (simple-array t (*)),
(or (simple-array string-char (*)),(or (simple-array internal-thin-char (*)) and
(simple-array bit (*)).
and add following :
Type simple-internal-thin-string means (simple-array
internal-thin-char (*)) and is a subtype of @B[internal-thin-string].
Type (simple-array string-char (*)) and simple-internal-thin-string are disjoint or
equality.
@b(4 Type Specifiers)
@b(4.1 Type Specifier Symbols)
add followings to system defined type specifiers :
simple-internal-thin-string
internal-thin-string
internal-thin-char
@b(4.5 Type Specifiers That Specialize)
"The specialized types (vector string-char) ... data types."
↓
"The specialized types (vector internal-thin-char), (vector
string-char) and (vector bit) are so useful that they have the
special names string and bit-vector. Every implementation of Common
Lisp must provide distinct representation for string and bit-vector
as distinct specialized data types."
@begin(equation)
@b(13 Characters)
@b(13.1 Character Attributes)
char-code-limit@>[constant]
char-font-limit@>[constant]
char-bits-limit@>[constant]
@b(13.2 Predicates on Characters)
standard-char-p char@>[constant]
graphic-char-p char@>[constant]
@begin(quotation)
a description "graphic characters of font 0 are all of the same width when printed" in
the CLtL changed to "standard-char without #\Newline of font 0 are all of the same
width when printed".
@end(quotation)
string-char-p char @>[function]
internal-thin-char-p char@>[function]
@begin(quotation)
this function must be added.
the argument char must be a character object. internal-thin-char-p
is true if char can be stored into a internal-thin-string, and
otherwise is false.
@end(quotation)
alpha-char-p char@>[function]
upper-case-p char@>[function]
lower-case-p char@>[function]
both-case-p char@>[function]
"If a character is either ... alphabetic."
↓
"If a character is either uppercase or lowercase, it is necessarily character
that alpha-char-p returns true."
digit-char-p char &optional (radix 10)@>[function]
alphanumericp char@>[function]
char= character &rest more-characters@>[function]
char/= character &rest more-characters@>[function]
char< character &rest more-characters@>[function]
char> character &rest more-characters@>[function]
char<= character &rest more-characters@>[function]
char>= character &rest more-characters@>[function]
char-equal character &rest more-characters@>[function]
char-not-equal character &rest more-characters@>[function]
char-lessp character &rest more-characters@>[function]
char-greaterp character &rest more-characters@>[function]
char-not-greaterp character &rest more-characters@>[function]
char-not-lessp character &rest more-characters@>[function]
@b(13.3 Character Construction and Selection)
char-code char@>[function]
char-bits char@>[function]
char-font char@>[function]
code-char char &optional (bits 0) (font 0)@>[function]
make-char char &optional (bits 0) (font 0)@>[function]
@b(13.4 Character Conversion)
character char@>[function]
char-upcase char@>[function]
char-downcase char@>[function]
digit-char weight &optional (radix 10) (font 0)@>[function]
char-int char@>[function]
int-char char@>[function]
char-name char@>[function]
name-char char@>[function]
@b(13.5 Character control-bit functions)
char-control-bit@>[constant]
char-meta-bit@>[constant]
char-super-bit@>[constant]
char-hyper-bit@>[constant]
char-bit char name@>[function]
set-char-bit char name newvalue@>[function]
@b(14 Sequence)
@b(14.1 Simple sequence functions)
elt sequence index@>[Function]
subseq sequence start &optional end@>[Function]
copy-seq sequence@>[Function]
length sequence@>[Function]
reverse sequence@>[Function]
nreverse sequence@>[Function]
make-sequence type size &key :initial-element@>[Function]
@b(14.2 Sequence connection)
concatenate result-type &rest sequences@>[Function]
map result-type function sequence &rest more-sequences@>[Function]
some predicate sequence &rest more-sequences@>[Function]
every predicate sequence &rest more-sequences@>[Function]
notany predicate sequence &rest more-sequences@>[Function]
notevery predicate sequence &rest more-sequences@>[Function]
reduce function sequence@>[Function]
&key :from-end :start :end :initial-value
@b(14.3 Sequence correction)
fill sequence item &key :start :end@>[Function]
replace sequence1 sequence2 &key :start1 :end1 :start2 :end2@>[Function]
remove item sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
remove-if test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-if-not test sequence@>[Function]
&key :from-end :start
:end :count :key
delete item sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
remove-if test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-if-not test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-duplicates sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
delete-duplicates sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
subsutitute newitem test sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
subsutitute-if newitem test sequence@>[Function]
&key :from-end :start :end :count :key
subsutitute-if-not newitem test sequence@>[Function]
&key :from-end :start :end :count :key
nsubsutitute newitem test sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
nsubsutitute-if newitem test sequence@>[Function]
&key :from-end :start :end :count :key
nsubsutitute-if-not newitem test sequence@>[Function]
&key :from-end :start :end :count :key
@b(14.4 Search)
find item sequence @>[Function]
&key :from-end :test :test-not
:start :end :key
find-if test sequence @>[Function]
&key :from-end :start :end :key
find-if-not test sequence>[Function]
&key :from-end :start :end :key
position item sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
position-if test sequence@>[Function]
&key :from-end :start :end :key
position-if-not test sequence@>[Function]
&key :from-end :start :end :key
count item sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
count-if item sequence@>[Function]
&key :from-end :start :end :key
count-if-not item sequence@>[Function]
&key :from-end :start :end :key
mismatch sequence1 sequence2@>[Function]
&key :from-end :test :test-not
:key :start1 :start2
:end1 :end2
search sequence1 sequence2@>[Function]
&key :from-end :test :test-not
:key :start1 :start2
:end1 :end2
@b(14.5 Sort,merge)
sort sequence predicate &key :key@>[Function]
stable-sort sequence predicate &key :key@>[Function]
merge result-type sequence1 sequence2 predicate &key :key@>[Function]
@b(18 Strings)
"the type string is identical ... (array string-char (*))."
↓
"the type string is identical to the type
(or (vector internal-thin-char) (vector string-char)),
which in turn is the same as (or (array internal-thin-char (*))
(array string-char (*)))."
@b(18.3 String Construction and Manipulation)
make-string size &key :initial-element@>[function]
@begin(quotation)
add following :
To make an internal-thin-string, you should use make-array or make-sequence.
@end(quotation)
@b(22 Input/Output)
@b(22.2 Input Functions)
@b(22.2.1 Output to Character Stream)
add following :
*read-default-string-type*@>[variables]
@begin(quotation)
The value is string or internal-thin-string. This determines string that the function
read takes whether type string or internal-thin-string.
@end(quotation)
@b(22.3 Output Functions)
@b(22.3.1 Output from Character Stream)
@begin(quotation)
add following :
@end(quotation)
write-width object@>[function]
&key :unit-type :stream :escape :radix :base
:circle :pretty :label :length :case :gensym :array
@begin(quotation)
This function returns the printed width as the value of the unit
specified by :unit-type when then printed representation of
object is written to the output stream specified by :stream. It
returns nil when object includes control characters
(#\Newline,#\Tab etc). The default of :unit-type is byte. The
value which we can specify :unit-type depends on implementation.
@end(quotation)
@end(equation)
@newpage
@Heading[Appendix Proposed Japanese character processing facilities for Common Lisp.]
In addition to the modification of CLtL, here are some suggestions for systems
including Japanese characters.
1). How should system behave for Japanese characters both
under unmodified part of CLtL and the part changed for multi-byte
processing.
2). About function that are specific to Japanese and no at all related
to multi-byte processing.
Notes: All Japanese characters are constituent. JIS is a abreviation of Japanese Industry
Standard.
@begin(equation)
@b(13. Characters)
@b(13.1. Character Attributes)
char-code-limit char @>[Function]
@begin(quotation)
The value of char-code-limit should be large enough to include Japanese characters,
e.g. 65536.
@end(quotation)
@b(13.2. Predicates on Characters)
standard-char-p char @>[Function]
@begin(quotation)
Return nil for all Japanese characters.
@end(quotation)
graphic-char-p char @>[Function]
@begin(quotation)
Return t for Japanese characters.
@end(quotation)
internal-thin-char-p char @>[Function]
@begin(quotation)
The result depends on each implementation that whether the Japanese character is in
internal-thin-string or not.
@end(quotation)
alpha-char-p char @>[Function]
@begin(quotation)
Return nil for all character except alphabets in Japanese character. It depends on
each implementation whether to return t or nil for alphabets in Japanese characters.
@end(quotation)
@newpage
jis-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object. jis-char-p is true if the
argument is included in JIS C-6226, and otherwise false.
@end(quotation)
japanese-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object. japanese-char-p is true if the
argument is a Japanese character and is otherwise false. All characters that satisfy
jis-char-p must satisfy japanese-char-p; other characters might.
@end(quotation)
kanji-char-p char@>[Function]
@begin(quotation)
The argument char has to be character type object. kanji-char-p is true if the
argument is one of the 6353 Kanji characters in JIS C6226(3.1.8), the repeat symbol,
the kanji numeric zero or the same as above symbol for a total of 6356 characters
that also satisfy jis-char-p.
@end(quotation)
hiragana-char-p char@>[Function]
@begin(quotation)
The argument char has to be character type object.
hiragana-char-p is true if the argument is one of the 83
hiragana characters in JIS C6226(3.1.4), the hiragana repeat
symbol, or dakuten for a total of 85 characters that also
satisfy jis-char-p.
@end(quotation)
katakana-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object.
katakana-char-p is true if the argument is one of the 86
hiragana characters in JIS C6226(3.1.5), long-sound-symbol,
katakana-repeat symbol, or katakana-dakuten for a total of 89
characters that also satisfy jis-char-p.
@end(quotation)
kana-char-p char@>[Function]
@begin(quotation)
equivalence (or (hiragana-char-p char) (katakana-char-p char))
@end(quotation)
upper-case-p char@>[Function]
lower-case-p char@>[Function]
both-case-p char@>[Function]
@begin(quotation)
These are nil if the argument does not satisfy alpha-char-p.
Japanese characters which satisfy alpha-char-p should be treated
as normal alphabetic characters.
@end(quotation)
@newpage
digit-char-p char &optional (radix 10)@>[Function]
@begin(quotation)
digit-char-p is nil if the argument is a Japanese character.
@end(quotation)
alphanumericp char@>[Function]
@begin(quotation)
equivalence (or (alpha-char-p char) (not (null (digit-char-p char))))
@end(quotation)
char= character &rest more-characters@>[Function]
char/= character &rest more-characters@>[Function]
char< character &rest more-characters@>[Function]
char> character &rest more-characters@>[Function]
char<= character &rest more-characters@>[Function]
char>= character &rest more-characters@>[Function]
@begin(quotation)
The ordering of hiragana, katakana, kanji follows the JIS ordering.
@end(quotation)
@b(13.4 character Conversions)
char-upcase char@>[Function]
char-downcast char@>[Function]
@begin(quotation)
These return the argument if the argument does not satisfy
alpha-char-p. It depends on the implementation whether these
work on the alphabets included in JIS or not. But it should be
consistent with upper-case-p, lower-case-p, both-case-p.
@end(quotation)
@end(equation)
∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 1 of 2
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:13:44 PDT
Return-Path: <RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU>
Date: Sat, 30 May 87 09:56 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX part 1 of 2
To: MATHIS@ADA20.ISI.EDU
Message-ID: <870530095642.5.RWS@KILLINGTON.LCS.MIT.EDU>
ReSent-To: x3j13@SAIL.STANFORD.EDU
ReSent-From: MATHIS at ADA20.ISI.EDU
ReSent-Date: 31 May 1987
;;; -*- Mode: LISP; Syntax: Common-lisp; Package: (XLIB (CL)); Base: 10; Lowercase: Yes -*-
;; Draft Version 3.1 (corresponds to Alpha Update protocol document)
;; Author:
;; Robert W. Scheifler
;; Laboratory for Computer Science
;; 545 Technology Square, Room 418
;; Cambridge, MA 02139
;; rws@zermatt.lcs.mit.edu
;; Contributors:
;; Dan Cerys, Texas Instruments
;; Scott Fahlman, CMU
;; Kerry Kimbrough, Texas Instruments
;; Chris Lindblad, MIT
;; Rob MacLachlan, CMU
;; Mike McMahon, Symbolics
;; David Moon, Symbolics
;; LaMott Oren, Texas Instruments
;; Daniel Weinreb, Symbolics
;; John Wroclawski, MIT
;; Richard Zippel, Symbolics
;; Note: all of the following is in the package XLIB.
;; Note: various perversions of the CL type system are used below.
;; Examples: (list elt-type) (sequence elt-type)
(proclaim '(declaration arglist values))
;; Note: if you have read the Version 11 protocol document or C Xlib manual, most of
;; the relationships should be fairly obvious. We have no intention of writing yet
;; another moby document for this interface.
;; Types employed: display, window, pixmap, cursor, font, gcontext, colormap, color.
;; These types are defined solely by a functional interface; we do not specify
;; whether they are implemented as structures or flavors or ... Although functions
;; below are written using DEFUN, this is not an implementation requirement (although
;; it is a requirement that they be functions as opposed to macros or special forms).
;; It is unclear whether with-slots in the Common Lisp Object System must work on
;; them.
;; Windows, pixmaps, cursors, fonts, gcontexts, and colormaps are all represented as
;; compound objects, rather than as integer resource-ids. This allows applications
;; to deal with multiple displays without having an explicit display argument in the
;; most common functions. Every function uses the display object indicated by the
;; first argument that is or contains a display; it is an error if arguments contain
;; different displays, and predictable results are not guaranteed.
;; Each of window, pixmap, cursor, font, gcontext, and colormap have the following
;; five functions:
(defun make-<mumble> (display resource-id)
;; This function should almost never be called by applications, except in handling
;; events. To minimize consing in some implementations, this may use a cache in
;; the display. Make-gcontext creates with :cache-p nil. Make-font creates with
;; cache-p true.
(declare (type display display)
(type integer resource-id)
(values <mumble>)))
(defun <mumble>-display (<mumble>)
(declare (type <mumble> <mumble>)
(values display)))
(defun <mumble>-id (<mumble>)
(declare (type <mumble> <mumble>)
(values integer)))
(defun <mumble>-equal (<mumble>-1 <mumble>-2)
(declare (type <mumble> <mumble>-1 <mumble>-2)))
(defun <mumble>-p (<mumble>-1 <mumble>-2)
(declare (type <mumble> <mumble>-1 <mumble>-2)
(values boolean)))
;; The following functions are provided by color objects:
;; The intention is that IHS and YIQ and CYM interfaces will also exist. Note that
;; we are explicitly using a different spectrum representation than what is actually
;; transmitted in the protocol.
(defun make-color (&key red green blue &allow-other-keys) ; for expansion
(declare (type (number 0 1) red green blue)
(values color)))
(defun color-rgb (color)
(declare (type color color)
(values red green blue)))
(defun color-red (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(defun color-green (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(defun color-blue (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(deftype resource-id () 'integer)
(deftype drawable () '(or window pixmap))
;; Atoms are accepted as strings or symbols, and are always returned as keywords.
;; Protocol-level integer atom ids are hidden, using a cache in the display object.
(deftype xatom () '(or string symbol))
(deftype stringable () '(or string symbol))
(deftype fontable () '(or stringable font))
;; Nil stands for CurrentTime.
(deftype timestamp () '(or null integer))
(deftype bit-gravity () '(member :forget :static :north-west :north :north-east
:west :center :east :south-west :south :south-east))
(deftype win-gravity () '(member :unmap :static :north-west :north :north-east
:west :center :east :south-west :south :south-east))
(deftype grab-status ()
'(member :success :already-grabbed :frozen :invalid-time :not-viewable))
(deftype boolean () '(or null (not null)))
;; An association list.
(deftype alist (key-type-and-name datum-type-and-name) 'list)
;; A sequence, containing zero or more repetitions of the given elements,
;; with the elements expressed as (type name).
(deftype repeat-seq (&rest elts) 'sequence)
(deftype point-seq () '(repeat-seq (integer x) (integer y)))
(deftype seg-seq () '(repeat-seq (integer x1) (integer y1) (integer x2) (integer y2)))
(deftype rect-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)))
;; Note that we are explicitly using a different angle representation than what
;; is actually transmitted in the protocol.
(deftype angle () `(number ,(* -2 pi) ,(* 2 pi)))
(deftype arc-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)
(angle angle1) (angle angle2)))
(deftype event-mask-class ()
'(member :key-press :key-release :owner-grab-button :button-press :button-release
:enter-window :leave-window :pointer-motion :pointer-motion-hint
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion :exposure :visibility-change
:structure-notify :resize-redirect :substructure-notify :substructure-redirect
:focus-change :property-change :colormap-change :keymap-state))
(deftype event-mask ()
'(or integer (list event-mask-class)))
(deftype pointer-event-mask-class ()
'(member :button-press :button-release
:enter-window :leave-window :pointer-motion :pointer-motion-hint
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion :keymap-state))
(deftype pointer-event-mask ()
'(or integer (list pointer-event-mask-class)))
(deftype device-event-mask-class ()
'(member :key-press :key-release :button-press :button-release :pointer-motion
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion))
(deftype device-event-mask ()
'(or integer (list device-event-mask-class)))
(deftype modifier-key ()
'(member :shift :caps-lock :control :mod-1 :mod-2 :mod-3 :mod-4 :mod-5))
(deftype modifier-mask ()
'(or (member :any) integer (list modifier-key)))
(deftype state-mask-key ()
'(or modifier-key (member :button-1 :button-2 :button-3 :button-4 :button-5)))
(deftype gcontext-key ()
'(member :function :plane-mask :foreground :background
:line-width :line-style :cap-style :join-style :fill-style :fill-rule
:arc-mode :tile :stipple :ts-x :ts-y :font :subwindow-mode
:exposures :clip-x :clip-y :clip-mask :clip-ordering
:dash-offset :dashes))
(deftype event-key ()
'(member :key-press :key-release :button-press :button-release :motion-notify
:enter-notify :leave-notify :focus-in :focus-out :keymap-notify
:exposure :graphics-exposure :no-exposure :visibility-notify
:create-notify :destroy-notify :unmap-notify :map-notify :map-request
:reparent-notify :configure-notify :gravity-notify :resize-request
:configure-request :circulate-notify :circulate-request :property-notify
:selection-clear :selection-request :selection-notify
:colormap-notify :client-message))
(deftype error-key ()
'(member :access :alloc :atom :colormap :cursor :drawable :font :gcontext :id-choice
:illegal-request :implementation :length :match :name :pixmap :property
:value :window))
(deftype draw-direction ()
'(member :left-to-right :right-to-left))
(defstruct bitmap-format
(unit <unspec> :type (member 8 16 32))
(pad <unspec> :type (member 8 16 32))
(lsb-first-p <unspec> :type boolean))
(defstruct pixmap-format
(depth <unspec> :type integer)
(bits-per-pixel <unspec> :type (member 4 8 16 32))
(pad <unspec> :type (member 8 16 32)))
(defstruct visual-info
(id <unspec> :type integer)
(class <unspec> :type (member :static-gray :static-color :true-color
:gray-scale :pseudo-color :direct-color))
(red-mask <unspec> :type integer)
(green-mask <unspec> :type integer)
(blue-mask <unspec> :type integer)
(bits-per-rgb <unspec> :type integer)
(colormap-entries <unspec> :type integer))
(defstruct screen
(root <unspec> :type window)
(device <unspec> :type integer)
(width <unspec> :type integer)
(height <unspec> :type integer)
(width-in-millimeters <unspec> :type integer)
(height-in-millimeters <unspec> :type integer)
(depths <unspec> :type (alist (integer depth) ((list visual-info) visuals)))
(root-depth <unspec> :type integer)
(root-visual <unspec> :type integer)
(default-colormap <unspec> :type colormap)
(white-pixel <unspec> :type integer)
(black-pixel <unspec> :type integer)
(min-installed-maps <unspec> :type integer)
(max-installed-maps <unspec> :type integer)
(backing-stores <unspec> :type (member :never :when-mapped :always))
(save-unders-p <unspec> :type boolean)
(event-mask-at-open <unspec> :type integer))
;; To allow efficient storage representations, the type char-info is not
;; required to be a structure.
(defun char-left-bearing (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-right-bearing (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-width (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-ascent (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-descent (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-attributes (char-info)
(declare (type char-info char-info)
(values integer)))
;; The list contains alternating keywords and integers.
(deftype font-props () 'list)
(defstruct font-info
(name <unspec> :type string)
(direction <unspec> :type draw-direction)
(min-char <unspec> :type integer)
(max-char <unspec> :type integer)
(min-byte1 <unspec> :type integer)
(max-byte1 <unspec> :type integer)
(min-byte2 <unspec> :type integer)
(max-byte2 <unspec> :type integer)
(all-chars-exist-p <unspec> :type boolean)
(default-char <unspec> :type integer)
(min-bounds <unspec> :type char-info)
(max-bounds <unspec> :type char-info)
(ascent <unspec> :type integer)
(descent <unspec> :type integer)
(properties <unspec> :type font-props))
(defun open-display (host &key (display 0) protocol)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; and protocol are not constrained, and will likely be very system dependent. The
;; default protocol is system specific. Authorization, if any, is assumed to come
;; from the environment somehow.
(declare (type integer display)
(values display)))
(defun display-protocol-version (display)
;; Values are integers.
(declare (type display display)
(values major minor)))
(defun display-vendor (display)
;; Values are string and integer
(declare (type display display)
(values name release)))
(defun display-image-lsb-first-p (display)
(declare (type display display)
(values boolean)))
(defun display-bitmap-formap (display)
(declare (type display display)
(values bitmap-format)))
(defun display-pixmap-formats (display)
(declare (type display display)
(values (list pixmap-formats))))
(defun display-roots (display)
(declare (type display display)
(values (list screen))))
(defun display-keyboard (display)
(declare (type display display)
(values integer)))
(defun display-pointer (display)
(declare (type display display)
(values integer)))
(defun display-motion-buffer-size (display)
(declare (type display display)
(values integer)))
(defun display-max-request-length (display)
(declare (type display display)
(values integer)))
(defun close-display (display)
(declare (type display display)))
(defun display-error-handler (display)
(declare (type display display)
(values handler)))
(defsetf display-error-handler (display) (handler)
;; All errors (synchronous and asynchronous) are processed by calling an error
;; handler in the display. If handler is a sequence it is expected to contain
;; handler functions specific to each error; the error code is used to index the
;; sequence, fetching the appropriate handler. Any results returned by the handler
;; are ignored; it is assumed the handler either takes care of the error
;; completely, or else signals. For all core errors, the keyword/value argument
;; pairs are:
;; :display display
;; :error-key error-key
;; :major integer
;; :minor integer
;; :sequence integer
;; :current-sequence integer
;; For :colormap, :cursor, :drawable, :font, :gcontext, :id-choice, :pixmap, and
;; :window errors another pair is:
;; :resource-id integer
;; For :atom errors, another pair is:
;; :atom-id integer
;; For :value errors, another pair is:
;; :value integer
(declare (type display display)
(type (or (sequence (function (&rest key-vals)))
(function (&rest key-vals)))
handler)))
(defmacro define-condition (name base &body items)
;; just a place-holder here for the real thing
)
(define-condition request-error error
display
major
minor
sequence
current-sequence)
(defun default-error-handler (&rest key-vals)
;; The default display-error-handler.
;; It signals the conditions listed below.
)
(define-condition resource-error request-error
resource-id)
(define-condition access-error request-error)
(define-condition alloc-error request-error)
(define-condition atom-error request-error
atom-id)
(define-condition colormap-error resource-error)
(define-condition cursor-error resource-error)
(define-condition drawable-error resource-error)
(define-condition font-error resource-error)
(define-condition gcontext-error resource-error)
(define-condition id-choice-error resource-error)
(define-condition illegal-request-error request-error)
(define-condition implementation-error request-error)
(define-condition length-error request-error)
(define-condition match-error request-error)
(define-condition name-error request-error)
(define-condition pixmap-error resource-error)
(define-condition property-error request-error)
(define-condition value-error request-error
value)
(define-condition window-error resource-error)
(defmacro with-display ((display) &body body)
;; This macro is for use in a multi-process environment. It provides exclusive
;; access to the local display object for multiple request generation. It need not
;; provide immediate exclusive access for replies; that is, if another process is
;; waiting for a reply (while not in a with-display), then synchronization need not
;; (but can) occur immediately. Except where noted, all routines effectively
;; contain an implicit with-display where needed, so that correct synchronization
;; is always provided at the interface level on a per-call basis. Nested uses of
;; this macro will work correctly. This macro does not prevent concurrent event
;; processing; see with-event-queue.
)
(defun display-force-output (display)
;; Output is normally buffered; this forces any buffered output.
(declare (type display display)))
(defun display-finish-output (display)
;; Forces output, then causes a round-trip to ensure that all possible errors and
;; events have been received.
(declare (type display display)))
(defun display-after-function (display)
;; setf'able
;; If defined, called after every protocol request is generated, even those inside
;; explicit with-display's, but never called from inside the after-function itself.
;; The function is called inside the effective with-display for the associated
;; request. Default value is nil. Can be set, for example, to
;; #'display-force-output or #'display-finish-output.
(declare (type display display)
(values (or null (function (display))))))
(defun create-window (&key parent x y width height (depth 0) (border-width 0)
(class :copy) (visual :copy)
background border gravity bit-gravity
backing-store backing-planes backing-pixel save-under
event-mask do-not-propagate-mask override-redirect
colormap cursor)
;; Display is obtained from parent. Only non-nil attributes are passed on in the
;; request: the function makes no assumptions about what the actual protocol
;; defaults are. Width and height are the inside size, excluding border.
(declare (type window parent)
(type integer x y width height depth border-width)
(type (member :copy :input-output :input-only) class)
(type (or (member :copy) visual) visual)
(type (or null (member :none :parent-relative) integer pixmap) background)
(type (or null (member :copy) integer pixmap) border)
(type (or null win-gravity) gravity)
(type (or null bit-gravity) bit-gravity)
(type (or null (member :not-useful :when-mapped :always) backing-store))
(type (or null integer) backing-planes backing-pixel)
(type (or null event-mask) event-mask)
(type (or null device-event-mask) do-not-propagate-mask)
(type (or null (member :on :off)) save-under override-redirect)
(type (or null (member :copy) colormap) colormap)
(type (or null (member :none) cursor) cursor)
(values window)))
(defun window-class (window)
(declare (type window window)
(values (member :input-output :input-only))))
(defun window-visual (window)
(declare (type window window)
(values integer)))
(defsetf window-background (window) (background)
(declare (type window window)
(type (or (member :none :parent-relative) integer pixmap) background)))
(defsetf window-border (window) (border)
(declare (type window window)
(type (or (member :copy) integer pixmap) border)))
(defun window-gravity (window)
;; setf'able
(declare (type window window)
(values win-gravity)))
(defun window-bit-gravity (window)
;; setf'able
(declare (type window window)
(values bit-gravity)))
(defun window-backing-store (window)
;; setf'able
(declare (type window window)
(values (member :not-useful :when-mapped :always))))
(defun window-backing-planes (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-backing-pixel (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-save-under (window)
;; setf'able
(declare (type window window)
(values (member :on :off))))
(defun window-event-mask (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-do-not-propagate-mask (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-override-redirect (window)
;; setf'able
(declare (type window window)
(values (member :on :off))))
(defun window-colormap (window)
(declare (type window window)
(values (or null colormap))))
(defsetf window-colormap (window) (colormap)
(declare (type window window)
(type (or (member :copy) colormap) colormap)))
(defsetf window-cursor (window) (cursor)
(declare (type window window)
(type (or (member :none) cursor) cursor)))
(defun window-colormap-installed-p (window)
(declare (type window window)
(values boolean)))
(defun window-all-event-masks (window)
(declare (type window window)
(values integer)))
(defun window-map-state (window)
(declare (type window window)
(values (member :unmapped :unviewable :viewable))))
(defsetf drawable-x (window) (x)
(declare (type window window)
(type integer x)))
(defsetf drawable-y (window) (y)
(declare (type window window)
(type integer y)))
(defsetf drawable-width (window) (width)
;; Inside width, excluding border.
(declare (type window window)
(type integer width)))
(defsetf drawable-height (window) (height)
;; Inside height, excluding border.
(declare (type window window)
(type integer height)))
(defsetf drawable-border-width (window) (border-width)
(declare (type window window)
(type integer border-width)))
(defsetf window-priority (window &optional sibling) (mode)
;; A bit strange, but retains setf form.
(declare (type window window)
(type (or null window) sibling)
(type (member :above :below :top-if :bottom-if :opposite) mode)))
(defmacro with-state ((drawable) &body body)
;; Allows a consistent view to be obtained of data returned by GetWindowAttributes
;; and GetGeometry, and allows a coherent update using ChangeWindowAttributes and
;; ConfigureWindow. The body is not surrounded by a with-display. Within the
;; indefinite scope of the body, on a per-process basis in a multi-process
;; environment, the first call within an Accessor Group on the specified drawable
;; (the object, not just the variable) causes the complete results of the protocol
;; request to be retained, and returned in any subsequent accessor calls. Calls
;; within a Setf Group are delayed, and executed in a single request on exit from
;; the body. In addition, if a call on a function within an Accessor Group follows
;; a call on a function in the corresponding Setf Group, then all delayed setfs for
;; that group are executed, any retained accessor information for that group is
;; discarded, the corresponding protocol request is (re)issued, and the results are
;; (again) retained, and returned in any subsequent accessor calls.
;; Accessor Group A (for GetWindowAttributes):
;; window-visual, window-class, window-gravity, window-bit-gravity,
;; window-backing-store, window-backing-planes, window-backing-pixel,
;; window-save-under, window-colormap, window-colormap-installed-p,
;; window-map-state, window-all-event-masks, window-event-mask,
;; window-do-not-propagate-mask, window-override-redirect
;; Setf Group A (for ChangeWindowAttributes):
;; window-gravity, window-bit-gravity, window-backing-store, window-backing-planes,
;; window-backing-pixel, window-save-under, window-event-mask,
;; window-do-not-propagate-mask, window-override-redirect, window-colormap,
;; window-cursor
;; Accessor Group G (for GetGeometry):
;; drawable-root, drawable-depth, drawable-x, drawable-y, drawable-width,
;; drawable-height, drawable-border-width
;; Setf Group G (for ConfigureWindow):
;; drawable-x, drawable-y, drawable-width, drawable-height, drawable-border-width,
;; window-priority
)
(defun destroy-window (window)
(declare (type window window)))
(defun destroy-subwindows (window)
(declare (type window window)))
(defun add-to-save-set (window)
(declare (type window window)))
(defun remove-from-save-set (window)
(declare (type window window)))
(defun reparent-window (window parent x y)
(declare (type window window parent)
(type integer x y)))
(defun map-window (window)
(declare (type window window)))
(defun map-subwindows (window)
(declare (type window window)))
(defun unmap-window (window)
(declare (type window window)))
(defun unmap-subwindows (window)
(declare (type window window)))
(defun circulate-window-up (window)
(declare (type window window)))
(defun circulate-window-down (window)
(declare (type window window)))
(defun drawable-root (drawable)
(declare (type drawable drawable)
(values drawable)))
(defun drawable-depth (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-x (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-y (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-width (drawable)
;; For windows, inside width, excluding border.
(declare (type drawable drawable)
(values integer)))
(defun drawable-height (drawable)
;; For windows, inside height, excluding border.
(declare (type drawable drawable)
(values integer)))
(defun drawable-border-width (drawable)
(declare (type drawable drawable)
(values integer)))
(defun query-tree (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence window) parent root)))
(defun change-property (window property data type format
&key (mode :replace) (start 0) end transform)
;; Start and end affect sub-sequence extracted from data.
;; Transform is applied to each extracted element.
(declare (type window window)
(type xatom property type)
(type (member 8 16 32) format)
(type sequence data)
(type (member :replace :prepend :append) mode)
(type integer start)
(type (or null integer) end)
(type (or null (function (t) integer)) transform)))
(defun delete-property (window property)
(declare (type window window)
(type xatom property)))
(defun get-property (window property
&key type (start 0) end delete-p (result-type 'list) transform)
;; Transform is applied to each integer retrieved.
(declare (type window window)
(type xatom property)
(type (or null xatom) type)
(type integer start)
(type (or null integer) end)
(type boolean delete-p)
(type type result-type)
(type (or null (function (integer) t)) transform)
(values data type format bytes-after)))
(defun rotate-properties (window properties &optional (delta 1))
;; Postive rotates left, negative rotates right (opposite of actual protocol request).
(declare (type window window)
(type (sequence xatom) properties)
(type integer delta)))
(defun list-properties (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence keyword))))
;; Although atom-ids are not visible in the normal user interface, atom-ids might
;; appear in window properties and other user data, so conversion hooks are needed.
(defun intern-atom (display name)
(declare (type display display)
(type xatom name)
(values integer)))
(defun find-atom (display name)
(declare (type display display)
(type xatom name)
(values (or null integer))))
(defun atom-name (display atom-id)
(declare (type display display)
(type integer atom-id)
(values keyword)))
(defun selection-owner (display selection)
(declare (type display display)
(type xatom selection)
(values (or null window))))
(defsetf selection-owner (display selection &optional time) (owner)
;; A bit strange, but retains setf form.
(declare (type display display)
(type xatom selection)
(type (or null window) owner)
(type timestamp time)))
(defun convert-selection (selection type requestor &optional property time)
(declare (type xatom selection type)
(type window requestor)
(type (or null xatom) property)
(type timestamp time)))
(defun send-event (window event-key event-mask &rest args
&key propagate-p display &allow-other-keys)
;; Additional arguments depend on event-key, and are as specified further below
;; with declare-event, except that both resource-ids and resource objects are
;; accepted in the event components. The display argument is only required if the
;; window is :pointer-window or :input-focus.
(declare (type (or window (member :pointer-window :input-focus)) window)
(type event-key event-key)
(type event-mask event-mask)
(type boolean propagate-p)
(type (or null display) display)))
(defun grab-pointer (window event-mask
&key owner-p sync-pointer-p sync-keyboard-p confine-to cursor time)
(declare (type window window)
(type pointer-event-mask event-mask)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or null window) confine-to)
(type (or null cursor) cursor)
(type timestamp time)
(values grab-status)))
(defun ungrab-pointer (display &key time)
(declare (type display display)
(type timestamp time)))
(defun grab-button (window button event-mask
&key (modifiers 0)
owner-p sync-pointer-p sync-keyboard-p confine-to cursor)
(declare (type window window)
(type (or (member :any) integer) button)
(type modifier-mask modifiers)
(type pointer-event-mask event-mask)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or null window) confine-to)
(type (or null cursor) cursor)))
(defun ungrab-button (window button &key (modifiers 0))
(declare (type window window)
(type (or (member :any) integer) button)
(type modifier-mask modifiers)))
(defun change-active-pointer-grab (display event-mask &optional cursor time)
(declare (type display display)
(type pointer-event-mask event-mask)
(type (or null cursor) cursor)
(type timestamp time)))
(defun grab-keyboard (window &key owner-p sync-pointer-p sync-keyboard-p time)
(declare (type window window)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type timestamp time)
(values grab-status)))
(defun ungrab-keyboard (display &key time)
(declare (type display display)
(type timestamp time)))
(defun grab-key (window key &key (modifiers 0) owner-p sync-pointer-p sync-keyboard-p)
(declare (type window window)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or (member :any) integer) key)
(type modifier-mask modifiers)))
(defun ungrab-key (window key &key (modifiers 0))
(declare (type window window)
(type (or (member :any) integer) key)
(type modifier-mask modifiers)))
(defun allow-events (display mode &optional time)
(declare (type display display)
(type (member :async-pointer :sync-pointer :reply-pointer
:async-keyboard :sync-keyboard :replay-keyboard)
mode)
(type timestamp time)))
(defun grab-server (display)
(declare (type display display)))
(defun ungrab-server (display)
(declare (type display display)))
(defmacro with-server-grabbed ((display) &body body)
;; The body is not surrounded by a with-display.
)
∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 2 of 2
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:14:09 PDT
Return-Path: <RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU>
Date: Sat, 30 May 87 09:57 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX part 2 of 2
To: MATHIS@ADA20.ISI.EDU
Message-ID: <870530095718.6.RWS@KILLINGTON.LCS.MIT.EDU>
ReSent-To: x3j13@SAIL.STANFORD.EDU
ReSent-From: MATHIS at ADA20.ISI.EDU
ReSent-Date: 31 May 1987
(defun query-pointer (window)
(declare (type window window)
(values x y same-screen-p child mask root-x root-y root)))
(defun pointer-position (window)
(declare (type window window)
(values x y same-screen-p)))
(defun global-pointer-position (display)
(declare (type display display)
(values root-x root-y root)))
(defun motion-events (window &key start stop (result-type 'list))
(declare (type window window)
(type timestamp start stop)
(type type result-type)
(values (repeat-seq (integer x) (integer y) (timestamp time)))))
(defun translate-coordinates (src src-x src-y dst)
;; If src and dst are not on the same screen, nil is returned.
(declare (type window src)
(type integer src-x src-y)
(type window dst)
(values dst-x dst-y child)))
(defun warp-pointer (dst dst-x dst-y)
(declare (type window dst)
(type integer dst-x dst-y)))
(defun warp-pointer-if-inside (dst dst-x dst-y src src-x src-y
&optional src-width src-height)
;; Passing in a zero src-width or src-height is a no-op. A null src-width or
;; src-height translates into a zero value in the protocol request.
(declare (type window dst src)
(type integer dst-x dst-y src-x src-y)
(type (or null integer) src-width src-height)))
(defun set-input-focus (display focus revert-to &optional time)
;; Setf ought to allow multiple values.
(declare (type display display)
(type (or (member :none :pointer-root) window) focus)
(type (member :none :parent :pointer-root) revert-to)
(type timestamp time)))
(defun input-focus (display)
(declare (type display display)
(values focus revert-to)))
(defun query-keymap (display)
(declare (type display display)
(values (bit-vector 256))))
(defun open-font (display name &optional (cache-p t))
;; Font objects may be cached and reference counted locally within the display
;; object. This function might not execute a with-display if the font is cached.
;; The protocol QueryFont request happens on-demand under the covers. If cache-p
;; is nil, QueryFont results are never cached locally.
(declare (type display display)
(type stringable name)
(type boolean cache-p)
(values font)))
(defun font-cache-p (font)
;; setf'able
(declare (type font font)
(values boolean)))
(defun font-font-info (font)
(declare (type font font)
(values font-info)))
;; For each component (<name> <unspec> :type <type>) of font-info,
;; there is a corresponding function:
(defun font-<name> (font)
(declare (type font font)
(values <type>)))
(defun font-property (font name)
(declare (type font font)
(type keyword name)
(values (or null integer))))
(defun font-char-infos (font)
(declare (type font font)
(values (array char-info))))
(defun font-char-info (font char)
(declare (type font font)
(type integer char)
(values (or null char-info))))
(defun font-char16-info (font first-byte second-byte)
(declare (type font font)
(type integer first-byte second-byte)
(values (or null char-info))))
(defun close-font (font)
;; This might not generate a protocol request if the font is reference counted
;; locally.
(declare (type font font)))
(defun text-extents (font string)
(declare (type (or font gcontext) font)
(type string string)
(values width ascent descent left right font-ascent font-descent direction)))
(defun text16-extents (font array &key bytes-p)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type (or font gcontext) font)
(type array array)
(type boolean bytes-p)
(values width ascent descent left right font-ascent font-descent direction)))
(defun text-width (font string)
(declare (type (or font gcontext) font)
(type string string)
(values integer)))
(defun text16-width (font array &key bytes-p)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type (or font gcontext) font)
(type array array)
(type boolean bytes-p)
(values integer)))
(defun list-fonts (display pattern &key (max-fonts 65535) (result-type 'list))
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence string))))
(defun list-fonts-with-info (display pattern &key (max-fonts 65535) (result-type 'list))
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence font-info))))
(defun font-path (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence (or string pathname)))))
(defsetf font-path (display) (paths)
(declare (type display display)
(type (sequence (or string pathname)) paths)))
(defun create-pixmap (&key width height depth drawable)
(declare (type integer width height depth)
(type drawable drawable)
(values pixmap)))
(defun free-pixmap (pixmap)
(declare (type pixmap pixmap)))
(defun create-gcontext (&key drawable function plane-mask foreground background
line-width line-style cap-style join-style fill-style fill-rule
arc-mode tile stipple ts-x ts-y font subwindow-mode
exposures clip-x clip-y clip-mask clip-ordering
dash-offset dashes
(cache-p t))
;; Only non-nil components are passed on in the request, but for effective caching
;; assumptions have to be made about what the actual protocol defaults are. For
;; all gcontext components, a value of nil causes the default gcontext value to be
;; used. For clip-mask, this implies that an empty rect-seq cannot be represented
;; as a list. Note: use of stringable as font will cause an implicit open-font.
;; Note: papers over protocol SetClipRectangles and SetDashes special cases. If
;; cache-p is true, then gcontext state is cached locally, and changing a gcontext
;; component will have no effect unless the new value differs from the cached
;; value. Component changes (setfs and with-gcontext) are always deferred
;; regardless of the cache mode, and sent over the protocol only when required by a
;; local operation or by an explicit call to force-gcontext-changes.
(declare (type drawable drawable)
(type (or null boole-constant) function)
(type (or null integer) plane-mask foreground background line-width
ts-x ts-y clip-x clip-y dash-offset)
(type (or null (member :solid :dash :double-dash)) line-style)
(type (or null (member :not-last :butt :round :projecting)) cap-style)
(type (or null (member :miter :round :bevel)) join-style)
(type (or null (member :solid :tiled :opaque-stippled :stippled)) fill-style)
(type (or null (member :even-odd :winding)) fill-rule)
(type (or null (member :chord :pie-slice)) arc-mode)
(type (or null pixmap) tile stipple)
(type (or null fontable) font)
(type (or null (member :clip-by-children :include-inferiors)) subwindow-mode)
(type (or null (member :on :off)) exposures)
(type (or null (member :none) pixmap rect-seq) clip-mask)
(type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
(type (or null (or integer (sequence integer))) dashes)
(type (or null integer) dash-offset)
(type boolean cache)
(values gcontext)))
;; For each argument to create-gcontext (except clip-mask and clip-ordering) declared
;; as (type <type> <name>), there is an accessor:
(defun gcontext-<name> (gcontext)
;; The value will be nil if the last value stored is unknown (e.g., the cache was
;; off, or the component was copied from a gcontext with unknown state).
(declare (type gcontext gcontext)
(values <type>)))
;; For each argument to create-gcontext (except clip-mask and clip-ordering) declared
;; as (type (or null <type>) <name>), there is a setf for the corresponding accessor:
(defsetf gcontext-<name> (gcontext) (value)
(declare (type gcontext gcontext)
(type <type> value)))
(defun gcontext-clip-mask (gcontext)
(declare (type gcontext gcontext)
(values (or null (member :none) pixmap rect-seq)
(or null (member :unsorted :y-sorted :yx-sorted :yx-banded)))))
(defsetf gcontext-clip-mask (gcontext &optional ordering) (clip-mask)
;; Is nil illegal here, or is it transformed to a vector?
;; A bit strange, but retains setf form.
(declare (type gcontext gcontext)
(type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
(type (or (member :none) pixmap rect-seq) clip-mask)))
(defun force-gcontext-changes (gcontext)
;; Force any delayed changes.
(declare (type gcontext gcontext)))
(defmacro with-gcontext ((gcontext &key
function plane-mask foreground background
line-width line-style cap-style join-style fill-style fill-rule
arc-mode tile stipple ts-x ts-y font subwindow-mode
exposures clip-x clip-y clip-mask clip-ordering
dashes dash-offset)
&body body)
;; Changes gcontext components within the dynamic scope of the body (i.e.,
;; indefinite scope and dynamic extent), on a per-process basis in a multi-process
;; environment. The body is not surrounded by a with-display. If cache-p is nil
;; or the some component states are unknown, this will implement save/restore by
;; creating a temporary gcontext and doing copy-gcontext-components to and from it.
)
(defun copy-gcontext-components (src dst &rest keys)
(declare (type gcontext src dst)
(type (list gcontext-key) keys)))
(defun copy-gcontext (src dst)
(declare (type gcontext src dst))
;; Copies all components.
)
(defun free-gcontext (gcontext)
(declare (type gcontext gcontext)))
(defun clear-area (window &key (x 0) (y 0) width height exposures-p)
;; Passing in a zero width or height is a no-op. A null width or height translates
;; into a zero value in the protocol request.
(declare (type window window)
(type integer x y)
(type (or null integer) width height)
(type boolean exposures-p)))
(defun copy-area (src gcontext src-x src-y width height dst dst-x dst-y)
(declare (type drawable src dst)
(type gcontext gcontext)
(type integer src-x src-y width height dst-x dst-y)))
(defun copy-plane (src gcontext plane src-x src-y width height dst dst-x dst-y)
(declare (type drawable src dst)
(type gcontext gcontext)
(type integer src-x src-y plane width height dst-x dst-y)))
(defun draw-point (drawable gcontext x y)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)))
(defun draw-points (drawable gcontext points &optional relative-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type point-seq points)
(type boolean relative-p)))
(defun draw-line (drawable gcontext x1 y1 x2 y2 &optional relative-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x1 y1 x2 y2)
(type boolean relative-p)))
(defun draw-lines (drawable gcontext points &key relative-p fill-p (shape :complex))
(declare (type drawable drawable)
(type gcontext gcontext)
(type point-seq points)
(type boolean relative-p fill-p)
(type (member :complex :non-convex :convex) shape)))
(defun draw-segments (drawable gcontext segments)
(declare (type drawable drawable)
(type gcontext gcontext)
(type seg-seq segments)))
(defun draw-rectangle (drawable gcontext x y width height &optional fill-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y width height)
(type boolean fill-p)))
(defun draw-rectangles (drawable gcontext rectangles &optional fill-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type rect-seq rectangles)
(type boolean fill-p)))
(defun draw-arc (drawable gcontext x y width height angle1 angle2 &optional fill-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y width height angle1 angle2)
(type boolean fill-p)))
(defun draw-arcs (drawable gcontext arcs &optional fill-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type arc-seq arcs)
(type boolean fill-p)))
;; The following image routines are bare minimum. It may be useful to define some
;; form of "image" object to hide representation details and format conversions. It
;; also may be useful to provide stream-oriented interfaces for reading and writing
;; the data.
(defun put-raw-image (drawable gcontext data
&key (start 0) depth x y width height (left-pad 0) format)
;; Data must be a sequence of 8-bit quantities, already in the appropriate format
;; for transmission; the caller is responsible for all byte and bit swapping and
;; compaction. Start is the starting index in data; the end is computed from the
;; other arguments.
(declare (type drawable drawable)
(type gcontext gcontext)
(type (sequence integer) data)
(type integer start depth x y width height left-pad)
(type (member :bitmap :xy-pixmap :z-pixmap) format)))
(defun get-raw-image (drawable &key data (start 0) x y width height (plane-mask -1) format
(result-type '(vector (unsigned-byte 8))))
;; If data is given, it is modified in place (and returned), otherwise a new
;; sequence is created and returned, with a size computed from the other arguments
;; and the returned depth. The sequence is filled with 8-bit quantities, in
;; transmission format; the caller is responsible for any byte and bit swapping and
;; compaction required for further local use.
(declare (type drawable drawable)
(type (or null (sequence integer)) data)
(type integer start x y width height plane-mask)
(type (member :xy-format z-format) format)
(values (sequence integer) depth visual)))
(defun draw-string (drawable gcontext x y string &key (start 0) end)
;; For 8-bit indexes only.
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified and char-infos are cached.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type string string)
(type (or null integer) end)))
(defun draw-text (drawable gcontext items)
;; For 8-bit indexes only.
;; Items is a flat sequence containing both triples and pairs of the form:
;; (integer x) (integer y) (string string)
;; :font (fontable font)
(declare (type drawable drawable)
(type gcontext gcontext)
(type sequence items)))
(defun draw-string16 (drawable gcontext x y array &key bytes-p (start 0) end)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified and char-infos are cached. If bytes-p is nil,
;; then array should be an array of integers to be treated as 16-bit quantities,
;; otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type array array)
(type boolean bytes-p)))
(defun draw-text16 (drawable gcontext items &key bytes-p)
;; Items is a flat sequence containing both triples and pairs of the form:
;; (integer x) (integer y) (array array)
;; :font (fontable font)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a (sub)string of even length,
;; treated as first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type sequence items)
(type boolean bytes-p)
(type (or null integer) end)))
(defun draw-image-string (drawable gcontext x y string &key (start 0) end)
;; For 8-bit indexes only.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type string string)
(type (or null integer) end)))
(defun draw-image-string16 (drawable gcontext x y array &key bytes-p (start 0) end)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a (sub)string of even length,
;; treated as first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type array array)
(type boolean bytes-p)
(type (or null integer) end)))
(defun create-colormap (visual window &optional alloc-p)
(declare (type integer visual)
(type window window)
(type boolean alloc-p)
(values colormap)))
(defun free-colormap (colormap)
(declare (type colormap colormap)))
(defun copy-colormap-and-free (colormap)
(declare (type colormap colormap)
(values colormap)))
(defun install-colormap (colormap)
(declare (type colormap colormap)))
(defun uninstall-colormap (colormap)
(declare (type colormap colormap)))
(defun installed-colormaps (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence colormap))))
(defun alloc-color (colormap color)
(declare (type colormap colormap)
(type (or stringable color) color)
(values pixel screen-color exact-color)))
(defun alloc-color-cells (colormap colors &key (planes 0) contiguous-p (result-type 'list))
(declare (type colormap colormap)
(type integer colors planes)
(type boolean contiguous-p)
(type type result-type)
(values (sequence pixel) (sequence mask))))
(defun alloc-color-planes (colormap colors
&key (reds 0) (greens 0) (blues 0)
contiguous-p (result-type 'list))
(declare (type colormap colormap)
(type integer colors reds greens blues)
(type boolean contiguous-p)
(type type result-type)
(values (sequence pixel) red-mask green-mask blue-mask)))
(defun free-colors (colormap pixels &optional (plane-mask 0))
(declare (type colormap colormap)
(type (sequence integer) pixels)
(type integer plane-mask)))
(defun store-color (colormap pixel spec &key (red-p t) (green-p t) (blue-p t))
(declare (type colormap colormap)
(type integer pixel)
(type (or stringable color) spec)
(type boolean red-p green-p blue-p)))
(defun store-colors (colormap specs &key (red-p t) (green-p t) (blue-p t))
;; If stringables are specified for colors, it is unspecified whether all
;; stringables are first resolved and then a single StoreColors protocol request is
;; issued, or whether multiple StoreColors protocol requests are issued.
(declare (type colormap colormap)
(type (repeat-seq (integer pixel) ((or stringable color) color)) specs)
(type boolean red-p green-p blue-p)))
(defun query-colors (colormap pixels &key (result-type 'list))
(declare (type colormap colormap)
(type (sequence integer) pixels)
(type type result-type)
(values (sequence color))))
(defun lookup-color (colormap name)
(declare (type colormap colormap)
(type stringable name)
(values screen-color true-color)))
(defun create-cursor (&key source mask x y foreground background)
(declare (type pixmap source)
(type (or null pixmap) mask)
(type integer x y)
(type color foreground background)
(values cursor)))
(defun create-glyph-cursor (&key source-font source-char mask-font mask-char
foreground background)
(declare (type font source-font)
(type integer source-char)
(type (or null font) mask-font)
(type (or null integer) mask-char)
(type color foreground background)
(values cursor)))
(defun free-cursor (cursor)
(declare (type cursor cursor)))
(defun recolor-cursor (cursor foreground background)
(declare (type cursor cursor)
(type color foreground background)))
(defun query-best-cursor (width height display)
(declare (type integer width height)
(type display display)
(values width height)))
(defun query-best-tile (width height drawable)
(declare (type integer width height)
(type drawable drawable)
(values width height)))
(defun query-best-stipple (width height drawable)
(declare (type integer width height)
(type drawable drawable)
(values width height)))
(defun query-extension (display name)
(declare (type display display)
(type stringable name)
(values major-opcode first-event first-error)))
(defun list-extensions (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence string))))
(defun keyboard-mapping (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence integer))))
(define-condition device-busy error)
(defsetf keyboard-mapping (display) (map)
;; Can signal device-busy.
(declare (type display display)
(type (sequence integer) map)))
(defun change-keyboard-control (display &key key-click-percent
bell-percent bell-pitch bell-duration
led led-mode key auto-repeat-mode)
(declare (type display display)
(type (or null (member :default) integer) key-click-percent
bell-percent bell-pitch bell-duration)
(type (or null integer) led key)
(type (or null (member :on :off)) led-mode)
(type (or null (member :on :off :default)) auto-repeat-mode)))
(defun keyboard-control (display)
(declare (type display display)
(values key-click-percent bell-percent bell-pitch bell-duration
led-mask global-auto-repeat auto-repeats)))
(defun bell (display &optional (percent-from-normal 0))
;; It is assumed that an eventual audio extension to X will provide more complete
;; control.
(declare (type display display)
(type integer percent-from-normal)))
(defun pointer-mapping (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence integer))))
(defsetf pointer-mapping (display) (map)
;; Can signal device-busy.
(declare (type display display)
(type (sequence integer) map)))
(defun change-pointer-control (display &key acceleration threshold)
;; Acceleration is rationalized if necessary.
(declare (type display display)
(type (or null (member :default) number) acceleration)
(type (or null (member :default) integer) threshold)))
(defun pointer-control (display)
(declare (type display display)
(values acceleration threshold)))
(defun set-screen-saver (display timeout interval blanking exposures)
;; Setf ought to allow multiple values.
;; Timeout and interval are in seconds, will be rounded to minutes.
(declare (type display display)
(type (or (member :default) integer) timeout interval)
(type (member :yes :no :default) blanking exposures)))
(defun screen-saver (display)
;; Returns timeout and interval in seconds.
(declare (type display display)
(values timeout interval blanking exposures)))
(defun activate-screen-saver (display)
(declare (type display display)))
(defun reset-screen-saver (display)
(declare (type display display)))
(defun add-access-host (display host)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; are not constrained, and will likely be very system dependent.
(declare (type display display)))
(defun remove-access-host (display host)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; are not constrained, and will likely be very system dependent.
(declare (type display display)))
(defun access-hosts (display &key (result-type 'list))
;; The type of host objects returned is not constrained, except that the hosts must
;; be acceptable to add-access-host and remove-access-host.
(declare (type display display)
(type type result-type)
(values (sequence host) enabled-p)))
(defun access-control (display)
;; setf'able
(declare (type display display)
(values boolean)))
(defun close-down-mode (display)
;; setf'able
;; Cached locally in display object.
(declare (type display display)
(values (member :destroy :retain-permanent :retain-temporary))))
(defun kill-client (display resource-id)
(declare (type display display)
(type resource-id resource-id)))
(defun kill-temporary-clients (display)
(declare (type display display)))
(defun make-event-mask (&rest keys)
;; This is only defined for core events.
;; Useful for constructing event-mask, pointer-event-mask, device-event-mask.
(declare (type (list event-mask-class) keys)
(values integer)))
(defun make-event-keys (event-mask)
;; This is only defined for core events.
(declare (type integer event-mask)
(values (list event-mask-class))))
(defun make-state-mask (&rest keys)
;; Useful for constructing modifier-mask, state-mask.
(declare (type (list state-mask-key) keys)
(values integer)))
(defun make-state-keys (state-mask)
(declare (type integer mask)
(values (list state-mask-key))))
(defmacro with-event-queue ((display) &body body)
;; Grants exclusive access to event queue.
)
(defun event-listen (display &optional (timeout 0))
(declare (type display display)
(type (or null number) timeout))
;; Returns the number of events queued locally, if any, else nil. Hangs waiting
;; for events, forever if timeout is nil, else for the specified number of seconds.
)
(defun process-event (display &key handler timeout peek-p discard-p force-output-p)
;; If force-output-p is true, first invokes display-force-output. Invokes handler
;; on each queued event until handler returns non-nil, and that returned object is
;; then returned by process-event. If peek-p is true, then the event is not
;; removed from the queue. If discard-p is true, then events for which handler
;; returns nil are removed from the queue, otherwise they are left in place. Hangs
;; until non-nil is generated for some event, or for the specified timeout (in
;; seconds, if given); however, it is acceptable for an implementation to wait only
;; once on network data, and therefore timeout prematurely. Returns nil on
;; timeout. If handler is a sequence, it is expected to contain handler functions
;; specific to each event class; the event code is used to index the sequence,
;; fetching the appropriate handler. Handler is called with raw resource-ids, not
;; with resource objects. The arguments to the handler are described further below
;; using declare-event.
(declare (type display display)
(type (or (sequence (function (&rest key-vals) t))
(function (&rest key-vals) t))
handler)
(type (or null number) timeout)
(type boolean peek-p)))
(defmacro event-case ((display &key timeout peek-p discard-p force-output-p)
&body clauses)
(declare (arglist (display &key timeout peek-p discard-p force-output-p)
(event-or-events ((&rest args) |...|) &body body) |...|))
;; If force-output-p is true, first invokes display-force-output. Executes the
;; matching clause for each queued event until a clause returns non-nil, and that
;; returned object is then returned by event-case. If peek-p is true, then the
;; event is not removed from the queue. If discard-p is true, then events for
;; which the clause returns nil are removed from the queue, otherwise they are left
;; in place. Hangs until non-nil is generated for some event, or for the specified
;; timeout (in seconds, if given); however, it is acceptable for an implementation
;; to wait only once on network data, and therefore timeout prematurely. Returns
;; nil on timeout. In each clause, event-or-events is an event-key or a list of
;; event-keys (but they need not be typed as keywords) or the symbol t or otherwise
;; (but only in the last clause). The keys are not evaluated, and it is an error
;; for the same key to appear in more than one clause. Args is the list of event
;; components of interest; corresponding values (if any) are bound to variables
;; with these names (i.e., the args are variable names, not keywords, the keywords
;; are derived from the variable names). An arg can also be a (keyword var) form,
;; as for keyword args in a lambda lists. If no t/otherwise clause appears, it is
;; equivalent to having one that returns nil.
)
(defmacro declare-event (event-codes &rest declares)
;; Used to indicate the keyword arguments for handler functions in process-event
;; and event-case. All process-event handlers can have (display display) and
;; (event-key event-key) as keyword arguments, and an event-case clause can also
;; have event-key as an argument.
(declare (arglist event-key-or-keys &rest (type &rest keywords))))
(declare-event (:key-press :key-release :button-press :button-release)
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
;; for key-press and key-release, code is the keycode
;; for button-press and button-release, code is the button number
(integer code))
(declare-event :motion-notify
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
(boolean hint-p))
(declare-event (:enter-notify :leave-notify)
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
((member :normal :grab :ungrab) mode)
((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual) kind)
(boolean focus-p))
(declare-event (:focus-in :focus-out)
(resource-id window)
((member :normal :while-grabbed :grab :ungrab) mode)
((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual
:pointer :pointer-root :none)
kind))
(declare-event :keymap-notify
(resource-id window)
((bit-vector 256) keymap))
(declare-event :exposure
(resource-id window)
(integer x y width height)
(boolean last-p))
(declare-event :graphics-exposure
(resource-id drawable)
(integer x y width height major minor)
(boolean last-p))
(declare-event :no-exposure
(resource-id drawable)
(integer major minor))
(declare-event :visibility-notify
(resource-id window)
((member :unobscured :partially-obscured :fully-obscured) state))
(declare-event :create-notify
(resource-id window parent)
(integer x y width height border-width)
(boolean override-redirect-p))
(declare-event :destroy-notify
(resource-id event-window window))
(declare-event :unmap-notify
(resource-id event-window window)
(boolean configure-p))
(declare-event :map-notify
(resource-id event-window window)
(boolean override-redirect-p))
(declare-event :map-request
(resource-id parent window))
(declare-event :reparent-notify
(resource-id event-window window parent)
(integer x y)
(boolean override-redirect-p))
(declare-event :configure-notify
(resource-id event-window window)
(integer x y width height border-width)
((or null resource-id) above-sibling)
(boolean override-redirect-p))
(declare-event :gravity-notify
(resource-id event-window window)
(integer x y))
(declare-event :resize-request
(resource-id window)
(integer width height))
(declare-event :configure-request
(resource-id parent window)
(integer x y width height border-width)
((or null resource-id) above-sibling))
(declare-event :circulate-notify
(resource-id event-window window)
((member :top :bottom) place))
(declare-event :circulate-request
(resource-id parent window)
((member :top :bottom) place))
(declare-event :property-notify
(resource-id window)
(keyword atom)
((member :new-value :deleted) state)
(integer time))
(declare-event :selection-clear
(resource-id window)
(keyword selection)
(integer time))
(declare-event :selection-request
(resource-id window requestor)
(keyword selection target)
((or null keyword) property)
(integer time))
(declare-event :selection-notify
(resource-id window)
(keyword selection target)
((or null keyword) property)
(integer time))
(declare-event :colormap-notify
(resource-id window)
((or null resource-id) colormap)
(boolean new-p installed-p))
(declare-event :client-message
(resource-id window)
((member 8 16 32) format)
((sequence integer) data))
(defun queue-event (display event-key &rest args &key append-p &allow-other-keys)
;; The event is put at the head of the queue if append-p is nil, else the tail.
;; Additional arguments depend on event-key, and are as specified above with
;; declare-event, except that both resource-ids and resource objects are accepted
;; in the event components.
(declare (type display display)
(type event-key event-key)
(type boolean append-p)))
∂01-Jun-87 0532 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol script
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:32:24 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:31-EDT
Date: Mon, 1 Jun 87 08:31 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol script
To: x3j13@sail.stanford.edu
Message-ID: <870601083150.2.RWS@KILLINGTON.LCS.MIT.EDU>
Mathis requested that I mail out the X protocol document.
I just did, in 6 parts. If you are going to print it
out, and have access to a Unix system, below is a shell
script for generating a toc and an index. Be sure to
set the page length for your printer.
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
# paginate
# addindex
# This archive created: Fri May 29 11:37:31 1987
export PATH; PATH=/bin:/usr/bin:$PATH
if test -f 'paginate'
then
echo shar: "will not over-write existing file 'paginate'"
else
cat << \SHAR_EOF > 'paginate'
#!/bin/sh
# Hack attack.
# Assuming this program is stilled called paginate, it is intended to be
# in the form
# paginate spec
# It then generates the files
# spec.paged nearly the same as foo with the exception of
# a header on the top of each page. Pages are
# assumed to be 58 lines long before the header
# gets added.
# spec.toc A page number listing of all the lines that start
# with an upper case letter in column 1, up to but
# not including the first colon.
# spec.index An index built from the x11.spec.toc lines.
today="`date`"
linesPerPage=58
infile=$1
pagedfile=$1.paged
indexfile=$1.index
tocfile=$1.toc
addindex=addindex
wordsfile=/usr/tmp/$1.words
indexinput=/usr/tmp/$1.index-input
grepscript=/usr/tmp/$1.grep-script
rm -f $pagedfile $tocfile $indexfile $wordsfile $grepscript
rm -f $indexinput
echo "Paginating $infile into $pagedfile."
awk '
BEGIN {
date = "'"$today"'";
n = split(date, dateparts);
date = dateparts[3] " " dateparts[2] " " dateparts[6]
FS = ":";
input = "'$infile'";
paged = "'$pagedfile'";
toc = "'$tocfile'";
ind = "'$indexfile'";
words = "'$wordsfile'";
page = 1;
line = 0;
}
{
if ((line == 0) && (NF > 0))
printf("\n") > paged
print > paged
line = line + 1
if (line >= '$linesPerPage') {
page = page + 1
line = 0
printf("%c\n%s%42s%23s %d\n", 12, date, "X/V11 Protocol Specification", "Page", page) > paged
}
}
/↑[A-Z]/ {
l = $1;
while ((length(l) % 4) != 0)
l = l " "
while (length(l) < 70)
l = l " ."
if (l ~ /↑SECTION/)
printf("\n") > toc
printf("%s%5d\n", l, page) > toc
if (l !~ /↑SECTION/)
printf("\"%s\"\n", $1) > words
}
' $infile
cat $addindex >> $wordsfile
echo "Sorting $wordsfile."
sort -udf $wordsfile -o $wordsfile
echo "Generating $grepscript."
awk '{print "echo",$0, "; grep -n", $0, "'$infile'" > "'$grepscript'"}' $wordsfile
echo "Executing $grepscript to generate $indexinput."
sh $grepscript > $indexinput
echo "Producing $indexfile."
awk -F: '
BEGIN {
ind = "'$indexfile'";
}
/↑[A-Z]/ {
if (length(line) > 0)
printf("%s\n", line) > ind
line = sprintf("%-25s", $0)
separator = " "
lastPage = 0
}
/↑[0-9]/ {
pagen = ($1+'$linesPerPage'-1)/'$linesPerPage'
t = split(pagen, pageparts, ".")
page = pageparts[1]
if (lastPage != page)
{
if (length(line) > 73)
{
printf("%s,\n", line) > ind
line = sprintf("%-25s %d", " ", page)
}
else
line = line separator page
separator = ", "
lastPage = page
}
}
END {
printf("%s\n", line) > ind
}
' $indexinput
echo "Cleaning up."
#rm -f $wordsfile $grepscript $indexinput
SHAR_EOF
chmod +x 'paginate'
fi
if test -f 'addindex'
then
echo shar: "will not over-write existing file 'addindex'"
else
cat << \SHAR_EOF > 'addindex'
"OwnerGrabButton"
"EnterWindow"
"LeaveWindow"
"PointerMotion"
"PointerMotionHint"
"ButtonMotion"
"VisibilityChange"
"StructureNotify"
"ResizeRedirect"
"SubstructureNotify"
"SubstructureRedirect"
"FocusChange"
"PropertyChange"
"ColormapChange"
"KeymapState"
SHAR_EOF
fi
exit 0
# End of shell archive
∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 3 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:28:25 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:27-EDT
Date: Mon, 1 Jun 87 08:27 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 3 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082750.8.RWS@KILLINGTON.LCS.MIT.EDU>
GetGeometry
drawable: DRAWABLE
=>
root: WINDOW
depth: CARD8
x, y: INT16
width, height, border-width: CARD16
Errors: Drawable
Returns the root and (current) geometry of the drawable. Depth is the
number of bits per pixel for the object. X, y, and border-width will
always be zero for pixmaps. For a window, the x and y coordinates
specify the upper left outer corner of the window relative to its
parent's origin, and the width and height specify the inside size (not
including the border).
It is legal to pass an InputOnly window as a drawable to this request.
QueryTree
window: WINDOW
=>
root: WINDOW
parent: WINDOW or None
children: LISTofWINDOW
Errors: Window
Returns the root, the parent, and children of the window. The children
are listed in bottom-to-top stacking order.
InternAtom
name: STRING8
only-if-exists: BOOL
=>
atom: ATOM or None
Errors: Value, Alloc
Returns the atom for the given name. If only-if-exists is False, then
the atom is created if it does not exist. The string should use the
ASCII encoding, and upper/lower case matters.
The lifetime of an atom is not tied to the interning client. Atoms
remained defined until server reset (see Section 11).
GetAtomName
atom: ATOM
=>
name: STRING8
Errors: Atom
Returns the name for the given atom.
ChangeProperty
window: WINDOW
property, type: ATOM
format: {8, 16, 32}
mode: {Replace, Prepend, Append}
data: LISTofINT8 or LISTofINT16 or LISTofINT32
Errors: Window, Atom, Value, Match, Alloc
Alters the property for the specified window. The type is
uninterpreted by the server. The format specifies whether the data
should be viewed as a list of 8-bit, 16-bit, or 32-bit quantities, so
that the server can correctly byte-swap as necessary.
If mode is Replace, the previous property value is discarded. If the
mode is Prepend or Append, then the type and format must match the
existing property value (else a Match error); if the property is
undefined, it is treated as defined with the correct type and format
with zero-length data. For Prepend, the data is tacked on to the
beginning of the existing data, and for Append it is tacked on to the
end of the existing data.
Generates a PropertyNotify event on the window.
The lifetime of a property is not tied to the storing client.
Properties remain until explicitly deleted, or the window is destroyed,
or until server reset (see Section 11).
The maximum size of a property is server dependent.
DeleteProperty
window: WINDOW
property: ATOM
Errors: Window, Atom
Deletes the property from the specified window if the property exists.
Generates a PropertyNotify event on the window unless the property does
not exist.
GetProperty
window: WINDOW
property: ATOM
type: ATOM or AnyPropertyType
long-offset, long-length: CARD32
delete: BOOL
=>
type: ATOM
format: {8, 16, 32}
bytes-after: CARD32
value: LISTofINT8 or LISTofINT16 or LISTofINT32
Errors: Window, Atom, Property, Match, Value
If the specified property does not exist for the specifed window, a
Property error is generated. Otherwise, if type AnyPropertyType is
specified, (part of) the property is returned regardless of its type;
if a type is specified, (part of) the property is returned only if its
type equals the specified type (else a Match error). The actual type
and format of the property are returned.
Define the following values:
N = actual length of the stored property in bytes
(even if the format is 16 or 32)
I = 4 * long-offset
T = N - I
L = MINIMUM(T, 4 * long-length)
A = N - (I + L)
The returned value starts at byte index I in the property (indexing
from 0), and its length in bytes is L. It is a Value error if
long-offset is given such that L is negative. The value of bytes-after
is A, giving the number of trailing unread bytes in the stored
property.
If delete is True and bytes-after is zero, the property is also deleted
from the window and a PropertyNotify event is generated on the window.
RotateProperties
window: WINDOW
delta: INT8
properties: LISTofATOM
Errors: Window, Atom, Match
If the property names in the list are viewed as being numbered starting
from zero, and there are N property names in the list, then the value
associated with property name I becomes the value associated with
property name (I + delta) mod N, for all I from zero to N - 1. The
effect is to rotate the states by delta places around the virtual ring
of property names (right for positive delta, left for negative delta).
A PropertyNotify event is generated for each property, in the order
listed.
If an atom occurs more than once in the list or no property with that
name is defined for the window, a Match error is generated. If an Atom
or Match error is generated, no properties are changed.
ListProperties
window: WINDOW
=>
atoms: LISTofATOM
Errors: Window
Returns the atoms of properties currently defined on the window.
SetSelectionOwner
selection: ATOM
owner: WINDOW or None
time: TIMESTAMP or CurrentTime
Error: Atom, Window
Changes the owner and last-change time of the specifed selection. The
request has no effect if the specified time is earlier than the current
last-change time of the specified selection or is later than the
current server time; otherwise, the last-change time is set to the
specified time, with CurrentTime replaced by the current server time.
If the new owner is not the same as the current owner of the selection,
and the current owner is a window, then the current owner is sent a
SelectionClear event.
If the owner of a selection is a window, and the window is later
destroyed, the owner of the selection automatically reverts to None,
but the last-change time is not affected.
The selection atom is uninterpreted by the server.
Selections are global to the server.
GetSelectionOwner
selection: ATOM
=>
owner: WINDOW or None
Errors: Atom
Returns the current owner of the specified selection, if any.
ConvertSelection
selection, target: ATOM
property: ATOM or None
requestor: WINDOW
time: TIMESTAMP or CurrentTime
Error: Atom, Window
If the specified selection is owned by a window, the server sends a
SelectionRequest event to the owner. If no owner for the specified
selection exists, the server generates a SelectionNotify event to the
requestor with property None. The arguments are passed on unchanged in
either event.
SendEvent
destination: WINDOW or PointerWindow or InputFocus
propagate: BOOL
event-mask: SETofEVENT
event: <normal-event-format>
Errors: Window, Value
If PointerWindow is specified, destination is replaced with the window
that the pointer is in. If InputFocus is specified, then if the focus
window contains the pointer, destination is replaced with the window
that the pointer is in, and otherwise destination is replaced with the
focus window.
If propagate is False, then the event is sent to every client selecting
on destination any of the event types in event-mask.
If propagate is True and no clients have selected on destination any of
the event types in event-mask, then destination is replaced with the
closest ancestor of destination for which some client has selected a
type in event-mask and no intervening window has that type in its
do-not-propagate-mask. If no such window exists, or if the window is
an ancestor of the focus window and InputFocus was originally specified
as the destination, then the event is not sent to any clients.
Otherwise, the event is reported to every client selecting on the final
destination any of the types specified in event-mask.
The event code must be one of the core events, or one of the events
defined by an extension, so that the server can correctly byte swap the
contents as necessary. The contents of the event are otherwise
unaltered and unchecked by the server except to force on the most
significant bit of the event code.
Active grabs are ignored for this request.
GrabPointer
grab-window: WINDOW
owner-events: BOOL
event-mask: SETofPOINTEREVENT
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
confine-to: WINDOW or None
cursor: CURSOR or None
time: TIMESTAMP or CurrentTime
=>
status: {Success, AlreadyGrabbed, Frozen, InvalidTime, NotViewable}
Errors: Cursor, Window, Value
Actively grabs control of the pointer. Further pointer events are only
reported to the grabbing client. The request overrides any active
pointer grab by this client.
Event-mask is always augmented to include ButtonPress and
ButtonRelease. If owner-events is False, all generated pointer events
are reported with respect to grab-window, and are only reported if
selected by event-mask. If owner-events is True, then if a generated
pointer event would normally be reported to this client, it is reported
normally; otherwise the event is reported with respect to the
grab-window, and is only reported if selected by event-mask. For
either value of owner-events, unreported events are simply discarded.
Pointer-mode controls further processing of pointer events, and
keyboard-mode controls further processing of keyboard events. If the
mode is Asynchronous, event processing continues normally; if the
device is currently frozen by this client, then processing of events
for the device is resumed. If the mode is Synchronous, the device (as
seen via the protocol) appears to freeze, and no further events for
that device are generated by the server until the grabbing client
issues a releasing AllowEvents request. Actual device changes are not
lost while the device is frozen; they are simply queued for later
processing.
If a cursor is specified, then it is displayed regardless of what
window the pointer is in. If no cursor is specified, then when the
pointer is in grab-window or one of its subwindows, the normal cursor
for that window is displayed, and otherwise the cursor for grab-window
is displayed.
If a confine-to window is specified, then the pointer will be
restricted to stay contained in that window. The confine-to window
need have no relationship to the grab-window. If the pointer is not
initially in the confine-to window, then it is warped automatically to
the closest edge (and enter/leave events generated normally) just
before the grab activates. If the confine-to window is subsequently
reconfigured, the pointer will be warped automatically as necessary to
keep it contained in the window.
This request generates EnterNotify and LeaveNotify events.
The request fails with status AlreadyGrabbed if the pointer is actively
grabbed by some other client. The request fails with status Frozen if
the pointer is frozen by an active grab of another client. The request
fails with status NotViewable if grab-window or confine-to window is
not viewable. The request fails with status InvalidTime if the
specified time is earlier than the last-pointer-grab time or later than
the current server time; otherwise the last-pointer-grab time is set to
the specified time, with CurrentTime replaced by the current server
time.
UngrabPointer
time: TIMESTAMP or CurrentTime
Releases the pointer if this client has it actively grabbed (from
either GrabPointer or GrabButton or from a normal button press), and
releases any queued events. The request has no effect if the specified
time is earlier than the last-pointer-grab time or is later than the
current server time.
This request generates EnterNotify and LeaveNotify events.
An UngrabPointer is performed automatically if the event window or
confine-to window for an active pointer grab becomes not viewable.
GrabButton
modifiers: SETofKEYMASK or AnyModifier
button: BUTTON or AnyButton
grab-window: WINDOW
owner-events: BOOL
event-mask: SETofPOINTEREVENT
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
confine-to: WINDOW or None
cursor: CURSOR or None
Errors: Cursor, Window, Value, Access
This request establishes a passive grab. In the future, if the
specified button is pressed when the specified modifier keys are down
(and no other buttons or modifier keys are down), and grab-window
contains the pointer, and the confine-to window (if any) is viewable,
and these constraints are not satisfied for any ancestor, then the
pointer is actively grabbed as described in GrabPointer, the
last-pointer-grab time is set to the time at which the button was
pressed (as transmitted in the ButtonPress event), and the ButtonPress
event is reported. The interpretation of the remaining arguments is as
for GrabPointer. The active grab is terminated automatically when all
buttons are released (independent of the state of modifier keys).
A modifiers of AnyModifier is equivalent to issuing the request for all
possible modifier combinations. A button of AnyButton is equivalent to
issuing the request for all possible buttons.
An Access error is generated if some other client has already issued a
GrabButton with the same button/key combination on the same window.
When using AnyModifier or AnyButton, the request fails completely (no
grabs are established) if there is a conflicting grab for any
combination. The request has no effect on an active grab.
UngrabButton
modifiers: SETofKEYMASK or AnyModifier
button: BUTTON or AnyButton
grab-window: WINDOW
Errors: Window
Releases the passive button/key combination on the specified window if
it was grabbed by this client. A modifiers of AnyModifier is
equivalent to issuing the request for all possible modifier
combinations. A button of AnyButton is equivalent to issuing the
request for all possible buttons. Has no effect on an active grab.
ChangeActivePointerGrab
event-mask: SETofPOINTEREVENT
cursor: CURSOR or None
time: TIMESTAMP or CurrentTime
Errors: Cursor
Changes the specified dynamic parameters if the pointer is actively
grabbed by the client and the specified time is no earlier than the
last-pointer-grab time and no later than the current server time. The
interpretation of event-mask and cursor are as in GrabPointer. The
event-mask is always augmented to include ButtonPress and
ButtonRelease. Has no effect on the passive parameters of a
GrabButton.
GrabKeyboard
grab-window: WINDOW
owner-events: BOOL
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
time: TIMESTAMP or CurrentTime
=>
status: {Success, AlreadyGrabbed, Frozen, InvalidTime, NotViewable}
Errors: Window, Value
Actively grabs control of the keyboard. Further key events are
reported only to the grabbing client. The request overrides any active
keyboard grab by this client.
If owner-events is False, all generated key events are reported with
respect to grab-window. If owner-events is True, then if a generated
key event would normally be reported to this client, it is reported
normally; otherwise the event is reported with respect to the
grab-window. Both KeyPress and KeyRelease events are always reported,
independent of any event selection made by the client.
Pointer-mode controls further processing of pointer events, and
keyboard-mode controls further processing of keyboard events. If the
mode is Asynchronous, event processing continues normally; if the
device is currently frozen by this client, then processing of events
for the device is resumed. If the mode is Synchronous, the device (as
seen via the protocol) appears to freeze, and no further events for
that device are generated by the server until the grabbing client
issues a releasing AllowEvents request. Actual device changes are not
lost while the device is frozen; they are simply queued for later
processing.
This request generates FocusIn and FocusOut events.
The request fails with status AlreadyGrabbed if the keyboard is
actively grabbed by some other client. The request fails with status
Frozen if the keyboard is frozen by an active grab of another client.
The request fails with status NotViewable if grab-window is not
viewable. The request fails with status InvalidTime if the specified
time is earlier than the last-keyboard-grab time or later than the
current server time; otherwise the last-keyboard-grab time is set to
the specified time, with CurrentTime replaced by the current server
time.
UngrabKeyboard
time: TIMESTAMP or CurrentTime
Releases the keyboard if this client has it actively grabbed (from
either GrabKeyboard or GrabKey), and releases any queued events. The
request has no effect if the specified time is earlier than the
last-keyboard-grab time or is later than the current server time.
This request generates FocusIn and FocusOut events.
An UngrabKeyboard is performed automatically if the event window for an
active keyboard grab becomes not viewable.
GrabKey
key: KEYCODE or AnyNonModifier
modifiers: SETofKEYMASK or AnyModifier
grab-window: WINDOW
owner-events: BOOL
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
Errors: Window, Value, Access
This request establishes a passive grab on the keyboard. In the
future, if the specified key (which can itself be a modifier key) is
pressed when the specified modifier keys are down (and no other
modifier keys are down), and the KeyPress event would be generated in
grab-window or one of its inferiors, and these constraints are not
satisfied for any ancestor, then the keyboard is actively grabbed as
described in GrabKeyboard, the last-keyboard-grab time is set to the
time at which the key was pressed (as transmitted in the KeyPress
event), and the KeyPress event is reported. The interpretation of the
remaining arguments is as for GrabKeyboard. The active grab is
terminated automatically when the specified key has been released
(independent of the state of the modifier keys).
A modifiers of AnyModifier is equivalent to issuing the request for all
possible modifier combinations. A key of AnyNonModifier is equivalent
to issuing the request for all possible non-modifier key codes.
An Access error is generated if some other client has issued a GrabKey
with the same key combination on the same window. When using
AnyModifier or AnyNonModifier, the request fails completely (no grabs
are established) if there is a conflicting grab for any combination.
UngrabKey
key: KEYCODE or AnyNonModifier
modifiers: SETofKEYMASK or AnyModifier
grab-window: WINDOW
Errors: Window
Releases the key combination on the specified window if it was grabbed
by this client. A modifiers of AnyModifier is equivalent to issuing
the request for all possible modifier combinations. A key of
AnyNonModifier is equivalent to issuing the request for all possible
non-modifier key codes. Has no effect on an active grab.
AllowEvents
mode: {AsyncPointer, SyncPointer, ReplayPointer,
AsyncKeyboard, SyncKeyboard, ReplayKeyboard}
time: TIMESTAMP or CurrentTime
Errors: Value
Releases some queued events if the client has caused a device to
freeze. The request has no effect if the specified time is earlier
than the last-grab time of the most recent active grab for the client,
or if the specified time is later than the current server time.
For AsyncPointer, if the pointer is frozen by the client, pointer event
processing continues normally. If the pointer is frozen twice by the
client on behalf of two separate grabs, AsyncPointer "thaws" for both.
AsyncPointer has no effect if the pointer is not frozen by the client,
but the pointer need not be grabbed by the client.
For SyncPointer, if the pointer is frozen and actively grabbed by the
client, pointer event processing continues normally until the next
ButtonPress or ButtonRelease event is reported to the client, at which
time the pointer again appears to freeze. However if the reported
event causes the pointer grab to be released, then the pointer does not
freeze. SyncPointer has no effect if the pointer is not frozen by the
client, or if the pointer is not grabbed by the client.
For ReplayPointer, if the pointer is actively grabbed by the client and
is frozen as the result of an event having been sent to the client
(either from the activation of a GrabButton, or from a previous
AllowEvents with mode SyncPointer, but not from a GrabPointer), then
the pointer grab is released and that event is completely reprocessed,
but this time ignoring any passive grabs at or above (towards the root)
the grab-window of the grab just released. The request has no effect
if the pointer is not grabbed by the client, or if the pointer is not
frozen as the result of an event.
For AsyncKeyboard, if the keyboard is frozen by the client, keyboard
event processing continues normally. If the pointer is frozen twice by
the client on behalf of two separate grabs, AsyncPointer "thaws" for
both. AsyncKeyboard has no effect if the keyboard is not frozen by the
client, but the keyboard need not be grabbed by the client.
For SyncKeyboard, if the keyboard is frozen and actively grabbed by the
client, keyboard event processing continues normally until the next
KeyPress or KeyRelease event is reported to the client, at which time
the keyboard again appears to freeze. However if the reported event
causes the keyboard grab to be released, then the keyboard does not
freeze. SyncKeyboard has no effect if the keyboard is not frozen by
the client, or if the keyboard is not grabbed by the client.
For ReplayKeyboard, if the keyboard is actively grabbed by the client
and is frozen as the result of an event having been sent to the client
(either from the activation of a GrabKey, or from a previous
AllowEvents with mode SyncKeyboard, but not from a GrabKeyboard), then
the keyboard grab is released and that event is completely reprocessed,
but this time ignoring any passive grabs at or above (towards the root)
the grab-window of the grab just released. The request has no effect
if the keyboard is not grabbed by the client, or if the keyboard is not
frozen as the result of an event.
AsyncPointer, SyncPointer, and Replay Pointer have no effect on
processing of keyboard events. AsyncKeyboard, SyncKeyboard, and
ReplayKeyboard have no effect on processing of pointer events.
It is possible for both a pointer grab and a keyboard grab to be active
simultaneously (by the same or different clients). If a device is
frozen on behalf of either grab, no event processing is performed for
the device. It is possible for a single device to be frozen due to
both grabs. In this case, the freeze must be released on behalf of
both grabs before events can again be processed.
GrabServer
Disables processing of requests and close-downs on all other
connections (than the one this request arrived on).
UngrabServer
Restarts processing of requests and close-downs on other connections.
QueryPointer
window: WINDOW
=>
root: WINDOW
child: WINDOW or None
same-screen: BOOL
root-x, root-y, win-x, win-y: INT16
mask: SETofKEYBUTMASK
Errors: Window
The root window the pointer is currently on, and pointer coordinates
relative to the root's origin, are returned. If same-screen is False,
then the pointer is not on the same screen as the argument window, and
child is None and win-x and win-y are zero. If same-screen is True,
then win-x and win-y are the pointer coordinates relative to the
argument window's origin, and child is the child containing the
pointer, if any. The current state of the modifier keys and the
buttons are also returned.
GetMotionEvents
start, stop: TIMESTAMP or CurrentTime
window: WINDOW
=>
events: LISTofTIMECOORD
where
TIMECOORD: {x, y: CARD16
time: TIMESTAMP}
Error: Window
Returns all events in the motion history buffer that fall between the
specified start and stop times (inclusive) and that have coordinates
that lie within (including borders) the specified window at its present
placement. The x and y coordinates are reported relative to the origin
of the window.
TranslateCoordinates
src-window, dst-window: WINDOW
src-x, src-y: INT16
=>
same-screen: BOOL
child: WINDOW or None
dst-x, dst-y: INT16
Errors: Window
The src-x and src-y coordinates are taken relative to src-window's
origin, and returned as dst-x and dst-y coordinates relative to
dst-window's origin. If same-screen is False, then src-window and
dst-window are on different screens, and dst-x and dst-y are zero. If
the coordinates are contained in a mapped child of dst-window, then
that child is returned.
WarpPointer
src-window: WINDOW or None
dst-window: WINDOW
src-x, src-y: INT16
src-width, src-height: CARD16
dst-x, dst-y: INT16
Errors: Window
Moves the pointer to [dst-x, dst-y] relative to dst-window's origin.
If src-window is None, the move is independent of the current pointer
position, but if a window is specified, the move only takes place if
the pointer is currently contained in a visible portion of the
specified rectangle of the src-window.
The src-x and src-y coordinates are relative to src-window's origin.
If src-height is zero, it is replaced with the current height of
src-window minus src-y. If src-width is zero, it is replaced with the
current width of src-window minus src-x.
This request cannot be used to move the pointer outside the confine-to
window of an active pointer grab; an attempt will only move the pointer
as far as the closest edge of the confine-to window.
SetInputFocus
focus: WINDOW or PointerRoot or None
revert-to: {Parent, PointerRoot, None}
time: TIMESTAMP or CurrentTime
Errors: Window, Value
Changes the input focus and the last-focus-change time. The request
has no effect if the specified time is earlier than the current
last-focus-change time or is later than the current server time;
otherwise, the last-focus-change time is set to the specified time,
with CurrentTime replaced by the current server time.
If None is specified as the focus, all keyboard events are discarded
until a new focus window is set. In this case, the revert-to argument
is ignored.
If a window is specified as the focus, it becomes the keyboard's focus
window. If a generated keyboard event would normally be reported to
this window or one of its inferiors, the event is reported normally;
otherwise, the event is reported with respect to the focus window.
If PointerRoot is specified as the focus, the focus window is
dynamically taken to be the root window of whatever screen the pointer
is on at each keyboard event. In this case, the revert-to argument is
ignored.
This request generates FocusIn and FocusOut events.
If the focus window becomes not viewable, the new focus window depends
on the revert-to argument. If revert-to is Parent, the focus reverts
to the parent (or the closest viewable ancestor) and the new revert-to
value is take to be None. If revert-to is PointerRoot or None, the
focus reverts to that value. When the focus reverts, FocusIn and
FocusOut events are generated, but the last-focus-change time is not
affected.
GetInputFocus
=>
focus: WINDOW or PointerRoot or None
revert-to: {Parent, PointerRoot, None}
Returns the current focus state.
QueryKeymap
=>
keys: LISTofCARD8
Returns a bit vector for the keyboard; each one bit indicates that the
corresponding key is currently pressed. The vector is represented as
32 bytes. Byte N (from 0) contains the bits for keys 8N to 8N+7, with
the least significant bit in the byte representing key 8N.
OpenFont
fid: FONT
name: STRING8
Errors: IDChoice, Name, Alloc
Loads the specified font, if necessary, and associates identifier fid
with it. The font can be used as a source for any drawable. The font
name should use the ASCII encoding, and upper/lower case does not
matter.
CloseFont
font: FONT
Errors: Font
Deletes the association between the resource id and the font. The font
itself will be freed when no other resource references it.
∂01-Jun-87 0530 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 5 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:29:45 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:28-EDT
Date: Mon, 1 Jun 87 08:28 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 5 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082843.0.RWS@KILLINGTON.LCS.MIT.EDU>
PolyArc
drawable: DRAWABLE
gc: GCONTEXT
arcs: LISTofARC
Errors: Drawable, GContext, Match
Draws circular or elliptical arcs. Each arc is specified by a
rectangle and two angles. The x and y coordinates are relative to the
origin of the drawable, and define the upper left corner of the
rectangle. The center of the circle or ellipse is the center of the
rectangle, and the major and minor axes are specified by the width and
height, respectively. The angles are signed integers in degrees scaled
by 64, with positive indicating counterclockwise motion and negative
indicating clockwise motion. The start of the arc is specified by
angle1 relative to the three-oclock position from the center, and the
path and extent of the arc is specified by angle2 relative to the start
of the arc. If the magnitude of angle2 is greater than 360 degrees, it
is truncated to 360 degrees.
The arcs are drawn in the order listed. If the last point in one arc
coincides with the first point in the following arc, the two arcs will
join correctly. If the first point in the first arc coincides with the
last point in the last arc, the two arcs will join correctly. For any
given arc, no pixel is drawn more than once. If two arcs join
correctly and the line-width is greater than zero and the arcs
intersect, no pixel is drawn more than once. Otherwise, the
intersecting pixels of intersecting arcs are drawn multiple times.
Specifying an arc with one endpoint and a clockwise extent draws the
same pixels as specifying the other endpoint and an equivalent
counterclockwise extent, except as it affects joins.
By specifying one axis to be zero, a horizontal or vertical line can be
drawn.
Angles are computed based solely on the coordinate system, ignoring the
aspect ratio.
GC components: alu-function, plane-mask, line-width, line-style,
cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
FillPoly
drawable: DRAWABLE
gc: GCONTEXT
shape: {Complex, Nonconvex, Convex}
coordinate-mode: {Origin, Previous}
points: LISTofPOINT
Errors: Drawable, GContext, Match, Value
Fills the region closed by the specified path. The path is closed
automatically if the last point in the list does not coincide with the
first point. No pixel of the region is drawn more than once.
The first point is always relative to the drawable's origin; the rest
are relative either to that origin or the previous point, depending on
the coordinate-mode.
The shape parameter may be used by the server to improve performance.
Complex means the path may self-intersect.
Nonconvex means the path does not self-intersect, but the shape is not
wholly convex. If known by the client, specifying Nonconvex over
Complex may improve performance. If Nonconvex is specified for a
self-intersecting path, the graphics results are undefined.
Convex means the path is wholly convex. If known by the client,
specifying Convex can improve performance. If Convex is specified for
a path that is not convex, the graphics results are undefined.
GC components: alu-function, plane-mask, fill-style, fill-rule,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyFillRectangle
drawable: DRAWABLE
gc: GCONTEXT
rectangles: LISTofRECTANGLE
Errors: Drawable, GContext, Match
Fills the specified rectangles. The x and y coordinates of each
rectangle are relative to the drawable's origin, and define the upper
left corner of the rectangle.
The rectangles are drawn in the order listed. For any given rectangle,
no pixel is drawn more than once. If rectangles intersect, the
intersecting pixels are drawn multiple times.
GC components: alu-function, plane-mask, fill-style, fill-rule,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyFillArc
drawable: DRAWABLE
gc: GCONTEXT
arcs: LISTofARC
Errors: Drawable, GContext, Match
For each arc, fills the region closed by the specified arc and one or
two line segments, depending on the arc-mode. For Chord, the single
line segment joining the endpoints of the arc is used. For PieSlice,
the two line segments joining the endpoints of the arc with the center
point are used. The arcs are as specified in the PolyArc request.
The arcs are filled in the order listed. For any given arc, no pixel
is drawn more than once. If regions intersect, the intersecting pixels
are drawn multiple times.
GC components: alu-function, plane-mask, fill-style, fill-rule,
arc-mode, subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PutImage
drawable: DRAWABLE
gc: GCONTEXT
depth: CARD8
width, height: CARD16
dst-x, dst-y: INT16
left-pad: CARD8
format: {Bitmap, XYPixmap, ZPixmap}
bits: <bits>
Errors: Drawable, GContext, Match, Value, Alloc
Combines an image with a rectangle of the drawable. The dst-x and
dst-y coordinates are relative to the drawable's origin.
If Bitmap format is used, then depth must be one (else a Match error)
and the image must be in XYFormat. The foreground pixel in gc defines
the source for one bits in the image, and the background pixel defines
the source for the zero bits.
For XYPixmap and ZPixmap, depth must match the depth of drawable (else
a Match error). For XYPixmap, the image must be sent in XYFormat. For
ZPixmap, the image must be sent in the ZFormat defined for the given
depth.
The left-pad must be zero for ZPixmap format. For Bitmap and XYPixmap
format, left-pad must be less than bitmap-format-scanline-pad (as given
in the server connection setup info). The first left-pad bits in every
scanline are to be ignored by the server; the actual image begins that
many bits into the data. The width argument defines the width of the
actual image, and does not include left-pad.
GC components: alu-function, plane-mask, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background
GetImage
drawable: DRAWABLE
x, y: INT16
width, height: CARD16
plane-mask: CARD32
format: {XYFormat, ZFormat}
=>
depth: CARD8
visual: VISUALID or None
bits: <bits>
Errors: Drawable, Value, Match
Returns the contents of the given rectangle of the drawable in the
given format. The x and y coordinates are relative to the drawable's
origin, and define the upper left corner of the rectangle. If XYFormat
is specified, only the bit planes specified in plane-mask are
transmitted. If ZFormat is specified, then bits in all planes not
specified in plane-mask transmitted as zero. The returned depth
specifies the number of bits per pixel of the image. If the drawable
is a window, its visual type is returned; if the drawable is a pixmap,
the visual is None.
If the drawable is a window, the window must be mapped, and it must be
the case that, if there were no inferiors or overlapping windows, the
specified rectangle of the window would be fully visible on the screen
(else a Match error). The returned image will include any visible
portions of inferiors or overlapping windows contained in the
rectangle, but if these windows are of different depth than the
specified window, the contents returned for them are not defined by the
core protocol.
PolyText8
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
items: LISTofTEXTITEM8
where
TEXTITEM8: TEXTELT8 or FONT
TEXTELT8: [delta: INT8
string: STRING8]
Errors: Drawable, GContext, Match, Font
The x and y coordinates are relative to drawable's origin, and specify
the baseline starting position (the initial character origin). Each
text item is processed in turn. A font item causes the font to be
stored in gc, and to be used for subsequent text; switching among fonts
with differing draw-directions is permitted. A text element delta
specifies an additional change in the position along the x axis before
the string is drawn; the delta is always added to the character origin
(not added or subtracted based on the draw-direction of the current
font). Each character image, as defined by the font in gc, is treated
as an additional mask for a fill operation on the drawable.
All contained FONTs are always transmitted most significant byte first.
If a Font error is generated for an item, the previous items may have
been drawn.
For fonts defined with two-byte matrix indexing, each STRING8 byte is
interpreted as a byte2 value of a CHAR2B with a byte1 value of zero.
GC components: alu-function, plane-mask, fill-style, font,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyText16
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
items: LISTofTEXTITEM16
where
TEXTITEM16: TEXTELT16 or FONT
TEXTELT16: [delta-x: INT8
string: STRING16]
Errors: Drawable, GContext, Match, Font
Just like PolyText8, except two-byte (or 16-bit) characters are used.
For fonts defined with linear indexing rather than two-byte matrix
indexing, the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (i.e., byte1 of the
CHAR2B is taken as the most significant byte).
ImageText8
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
string: STRING8
Errors: Drawable, GContext, Match
The x and y coordinates are relative to drawable's origin, and specify
the baseline starting position (the initial character origin). The
effect is to first fill a destination rectangle with the background
pixel defined in gc, and then paint the text with the foreground pixel.
The upper left corner of the filled rectangle is at
[x + overall-left, y - font-ascent]
the width is
overall-right - overall-left
and the height is
font-ascent + font-descent
where overall-left, overall-right, font-ascent, and font-descent are as
would be returned by a QueryTextExtents call using gc and string.
The alu-function and fill-style defined in gc are ignored for this
request; the effective alu-function is Copy and the effective
fill-style Solid.
For fonts defined with two-byte matrix indexing, each STRING8 byte is
interpreted as a byte2 value of a CHAR2B with a byte1 value of zero.
GC components: plane-mask, foreground, background, font,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
ImageText16
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
string: STRING16
Errors: Drawable, GContext, Match
Just like ImageText8, except two-byte (or 16-bit) characters are used.
For fonts defined with linear indexing rather than two-byte matrix
indexing, the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (i.e., byte1 of the
CHAR2B is taken as the most significant byte).
CreateColormap
mid: COLORMAP
visual: VISUALID
window: WINDOW
alloc: {None, All}
Errors: IDChoice, Window, Value, Match, Alloc
Creates a colormap of the specified visual type for the screen on which
the window resides, and associates the identifier mid with it. The
visual type must be one supported by the screen, and cannot be of class
TrueColor (else a Match error). The initial values of the colormap
entries are undefined for classes GrayScale, PseudoColor, and
DirectColor; for StaticGray, StaticColor, and TrueColor, the entries
will have defined values, but those values are specific to the visual
and are not defined by the core protocol. For StaticGray, StaticColor,
and TrueColor, alloc must be specified as None (else a Match error).
For the other classes, if alloc is None, the colormap initially has no
allocated entries, and clients can allocate entries. If alloc is All,
then the entire colormap is "allocated" writable, but entries cannot be
freed with FreeColors, and no relationships among entries is defined;
the client must understand whether the colormap is GrayScale,
PseudoColor, or DirectColor to know how to store into entries.
FreeColormap
cmap: COLORMAP
Errors: Colormap
Deletes the association between the resource id and the colormap. If
the colormap is an installed map for a screen, it is uninstalled (see
UninstallColormap). If the colormap is defined as the colormap for a
window (via CreateWindow or ChangeWindowAttributes), the colormap for
the window is changed to None, and a ColormapNotify event is generated.
The colors displayed for a window with a colormap of None are not
defined by the protocol.
Has no effect on a default colormap for a screen.
CopyColormapAndFree
mid, src-cmap: COLORMAP
Errors: Colormap, Alloc
Creates a colormap for the same screen as src-cmap, and associates
identifier mid with it. Moves all of the client's existing allocations
from src-cmap to the new colormap, and frees those entries in src-cmap.
Values in other entries in the new colormap are undefined.
InstallColormap
cmap: COLORMAP
Errors: Colormap
Makes this colormap an installed map for its screen. All windows
associated with this colormap immediately display with true colors. As
a side-effect, previously installed colormaps may be uninstalled, and
other windows may display with false colors. Which colormaps get
uninstalled is server dependent, except that it is guaranteed that the
M-1 most recently client-installed colormaps will not be uninstalled,
where M is the min-installed-maps specified for the screen in the
connection setup.
If cmap is not already an installed map, a ColormapNotify event is
generated on every window having cmap as an attribute. If a colormap
is uninstalled as a result of the install, a ColormapNotify event is
generated on every window having that colormap as an attribute.
Initially only the default colormap for a screen is installed.
UninstallColormap
cmap: COLORMAP
Errors: Colormap
If cmap is an installed map for its screen, one or more colormaps are
installed in its place; the choice is server dependent, except that if
the screen's default colormap is not installed and can be installed
(without forcing other colormaps out), then the default colormap is
used.
If cmap is an installed map, a ColormapNotify event is generated on
every window having this colormap as an attribute. If a colormap is
installed as a result of the uninstall, a ColormapNotify event is
generated on every window having that colormap as an attribute.
ListInstalledColormaps
window: WINDOW
=>
cmaps: LISTofCOLORMAP
Errors: Window
Returns a list of the currently installed colormaps for the screen of
the specified window.
AllocColor
cmap: COLORMAP
red, green, blue: CARD16
=>
pixel: CARD32
red, green, blue: CARD16
Errors: Colormap, Alloc
Allocates a read-only colormap entry corresponding to the closest RGB
values provided by the hardware. Returns the pixel and the RGB values
actually used.
AllocNamedColor
cmap: COLORMAP
name: STRING8
=>
pixel: CARD32
exact-red, exact-green, exact-blue: CARD16
screen-red, screen-green, screen-blue: CARD16
Errors: Colormap, Name, Alloc
Looks up the named color with respect to the screen associated with the
colormap, then does an AllocColor on cmap. The name should use the
ASCII encoding, and upper/lower case does not matter. The exact RGB
values specify the "true" values for the color, and the screen values
specify the values actually used in the colormap.
AllocColorCells
cmap: COLORMAP
colors, planes: CARD16
contiguous: BOOL
=>
pixels, masks: LISTofCARD32
Errors: Colormap, Value, Alloc
The number of colors must be positive, the number of planes
non-negative. If C colors and P planes are requested, then C pixels
and P masks are returned. No mask will have any bits in common with
any other mask, or with any of the pixels. By ORing together masks and
pixels, C*(2↑P) distinct pixels can be produced; all of these are
allocated writable by the request. For GrayScale or PseudoColor, each
mask will have exactly one bit, and for DirectColor each will have
exactly three bits. If contiguous is True, then if all masks are ORed
together, a single contiguous set of bits will be formed for GrayScale
or PseudoColor, and three contiguous sets of bits (one within each
pixel subfield) for DirectColor. The RGB values of the allocated
entries are undefined.
AllocColorPlanes
cmap: COLORMAP
colors, reds, greens, blues: CARD16
contiguous: BOOL
=>
pixels: LISTofCARD32
red-mask, green-mask, blue-mask: CARD32
Errors; Colormap, Value, Alloc
The number of colors must be positive, the reds, greens, and blues
non-negative. If C colors, R reds, G greens, and B blues are
requested, then C pixels are returned, and the masks have R, G, and B
bits set respectively. If contiguous is True, then each mask will have
a contiguous set of bits. No mask will have any bits in common with
any other mask, or with any of the pixels. For DirectColor, each mask
will lie within the corresponding pixel subfield. By ORing together
subsets of masks with pixels, C*(2↑(R+G+B)) distinct pixels can be
produced; all of these are allocated by the request. The initial RGB
values of the allocated entries are undefined. In the colormap there
are only C*(2↑R) independent red entries, C*(2↑G) independent green
entries, and C*(2↑B) independent blue entries. This is true even for
PseudoColor. When the colormap entry for a pixel value is changed
using StoreColors or StoreNamedColor, the pixel is decomposed according
to the masks and the corresponding independent entries are updated.
FreeColors
cmap: COLORMAP
pixels: LISTofCARD32
plane-mask: CARD32
Errors: Colormap, Access, Value
The plane-mask should not have any bits in common with any of the
pixels. The set of all pixels is produced by ORing together subsets of
plane-mask with the pixels. The request frees all of these pixels.
Note that freeing an individual pixel obtained from AllocColorPlanes
may not actually allow it to be reused until all of its "related"
pixels are also freed.
All specified pixels that are allocated by the client in cmap are
freed, even if one or more pixels produce an error. A Value error is
generated if a specified pixel is not a valid index into cmap, and an
Access error is generated if a specified pixel is not allocated by the
client (i.e., is unallocated or is only allocated by another client).
If more than one pixel is in error, which one is reported is arbitrary.
StoreColors
cmap: COLORMAP
items: LISTofCOLORITEM
where
COLORITEM: [pixel: CARD32
do-red, do-green, do-blue: BOOL
red, green, blue: CARD16]
Errors: Colormap, Access, Value
Changes the colormap entries of the specified pixels. The do-red,
do-green, and do-blue fields indicate which components should actually
be changed. If the colormap is an installed map for its screen, the
changes are visible immediately.
All specified pixels that are allocated writable in cmap (by any
client) are changed, even if one or more pixels produce an error. A
Value error is generated if a specified pixel is not a valid index into
cmap, and an Access error is generated if a specified pixel is
unallocated or is allocated read-only. If more than one pixel is in
error, which one is reported is arbitrary.
StoreNamedColor
cmap: COLORMAP
pixel: CARD32
name: STRING8
do-red, do-green, do-blue: BOOL
Errors: Colormap, Name, Access, Value
Looks up the named color with respect to the screen associated with
cmap, then does a StoreColors in cmap. The name should use the ASCII
encoding, and upper/lower case does not matter.
QueryColors
cmap: COLORMAP
pixels: LISTofCARD32
=>
colors: LISTofRGB
where
RGB: [red, green, blue: CARD16]
Errors: Colormap, Value
Returns the color values stored in cmap for the specified pixels. The
values returned for an unallocated entry are undefined. A Value error
is generated if a pixel is not a valid index into cmap. If more than
one pixel is in error, which one is reported is arbitrary.
LookupColor
cmap: COLORMAP
name: STRING8
=>
exact-red, exact-green, exact-blue: CARD16
screen-red, screen-green, screen-blue: CARD16
Errors: Colormap, Name
Looks up the string name of a color with respect to the screen
associated with cmap, and returns both the exact the color values and
the closest values provided by the hardware. The name should use the
ASCII encoding, and upper/lower case does not matter.
CreateCursor
cid: CURSOR
source: PIXMAP
mask: PIXMAP or None
fore-red, fore-green, fore-blue: CARD16
back-red, back-green, back-blue: CARD16
x, y: CARD16
Errors: IDChoice, Bitmap, Match, Value, Alloc
Creates a cursor and associates identifier cid with it. Foreground and
background RGB values must be specified, even if the server only has a
monochrome screen. The foreground is used for the one bits in the
source, and the background is used for the zero bits. Both source and
mask (if specified) must have depth one (else a Match error), but can
have any root. The mask pixmap defines the shape of the cursor; that
is, the one bits in the mask define which source pixels will be
displayed. If no mask is given, all pixels of the source are
displayed. The mask, if present, must be the same size as source (else
a Match error). The x and y coordinates define the hotspot, relative
to the source's origin, and must be a point within the source (else a
Match error).
The components of the cursor may be transformed arbitrarily to meet
display limitations.
The pixmaps can be freed immediately if no further explicit references
to them are to be made.
Subsequent drawing in the source or mask pixmap has an undefined effect
on the cursor; the server might or might not make a copy of the pixmap.
CreateGlyphCursor
cid: CURSOR
source-font: FONT
mask-font: FONT or None
source-char, mask-char: CARD16
fore-red, fore-green, fore-blue: CARD16
back-red, back-green, back-blue: CARD16
Errors: IDChoice, Font, Value, Alloc
Similar to CreateCursor, but the source and mask bitmaps are obtained
from the specified font glyphs. The mask font and character are
optional. The origin of the source glyph defines the hotspot, and the
mask is positioned such that the origins are coincident. The source
and mask need not have the same bounding box metrics. If no mask is
given, all pixels of the source are displayed. Note that source-char
and mask-char are CARD16 (not CHAR2B); for two-byte matrix fonts, the
16-bit value should be formed with byte1 in the most significant byte
and byte2 in the least significant byte.
FreeCursor
cursor: CURSOR
Errors: Cursor
Deletes the association between the resource id and the cursor. The
cursor storage will be freed when no other resource references it.
RecolorCursor
cursor: CURSOR
fore-red, fore-green, fore-blue: CARD16
back-red, back-green, back-blue: CARD16
Errors: Cursor
Changes the color of a cursor. If the cursor is being displayed on a
screen, the change is visible immediately.
QueryBestSize
class: {Cursor, Tile, Stipple}
drawable: DRAWABLE
width, height: CARD16
=>
width, height: CARD16
Errors: Drawable, Value, Match
Returns the "best" size that is "closest" to the argument size. For
Cursor, this is the largest size that can be fully displayed. For
Tile, this is the size that can be tiled "fastest". For Stipple, this
is the size that can be stippled "fastest".
For Cursor, the drawable indicates the desired screen. For Tile and
Stipple, the drawable indicates screen, and also possibly window class
and depth; an InputOnly window cannot be used as the drawable for Tile
or Stipple (else a Match error).
QueryExtension
name: STRING8
=>
present: BOOL
major-opcode: CARD8
first-event: CARD8
first-error: CARD8
Determines if the named extension is present. If so, the major opcode
for the extension is returned, if it has one, otherwise zero is
returned. Any minor opcode and the request formats are specific to the
extension. If the extension involves additional event types, the base
event type code is returned, otherwise zero is returned. The format of
the events is specific to the extension. If the extension involves
additional error codes, the base error code is returned, otherwise
zero is returned. The format of additional data in the errors is
specific to the extension.
The extension name should be in the ASCII encoding, and upper/lower
case matters.
ListExtensions
=>
names: LISTofSTRING8
Returns a list of all extensions supported by the server.
SetKeyboardMapping
map: LISTofCARD8
=>
status: {Success, Busy}
Errors: Value
Sets the mapping of the keyboard. Elements of the list are indexed
starting from one. The list must be of length 255. The index is a
"core" keycode, and the element of the list defines the "effective"
keycode.
A zero element disables a key, no elements can have values 1 through 7,
and no two elements (with index larger than 7) can have the same
non-zero value. If the keyboard does not really generate a given
keycode, specifying a non-zero value for that core keycode has no
effect.
Elements 6 and 7 of the map must always be zero. The first five
elements are special: they specify the keycodes (if any) that
correspond to the Mod1 through Mod5 modifiers. Setting one of these
entries to zero disables use of that modifier bit. No two of the first
five elements can have the same non-zero value.
A server can impose restrictions on how keyboards get remapped, e.g.,
if certain keys do not generate up transitions in hardware.
If any of the keys or modifiers to be altered are currently in the down
state, the status reply is Busy and the mapping is not changed.
GetKeyboardMapping
=>
map: LISTofCARD8
Errors: Value
Returns the current mapping of the keyboard. Elements of the list are
indexed starting from one. The length of the list is 255.
The nominal mapping for a keyboard is almost the identity mapping,
except that map[i]=0 for keycodes that have no corresponding physical
key, and the first five entries indicate the keycodes (if any)
corresponding to the Mod1 through Mod5 modifier bits.
ChangeKeyboardControl
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Match, Value
Controls various aspects of the keyboard. The value-mask and
value-list specify which controls are to be changed. The possible
values are:
key-click-percent: INT8
bell-percent: INT8
bell-pitch: INT16
bell-duration: INT16
led: CARD8
led-mode: {On, Off}
key: KEYCODE
auto-repeat-mode: {On, Off, Default}
Key-click-percent sets the volume for key clicks between 0 (off) and
100 (loud) inclusive, if possible. Setting to -1 restores the default.
Other negative values generate a Value error.
Bell-percent sets the base volume for the bell between 0 (off) and 100
(loud) inclusive, if possible. Setting to -1 restores the default.
Other negative values generate a Value error.
Bell-pitch sets the pitch (specified in Hz) of the bell, if possible.
Setting to -1 restores the default. Other negative values generate a
Value error.
Bell-duration sets the duration (specified in milliseconds) of the
bell, if possible. Setting to -1 restores the default. Other negative
values generate a Value error.
If both led-mode and led are specified, then the state of that LED is
changed, if possible. If only led-mode is specified, then the state of
all LEDs are changed, if possible. At most 32 LEDs are supported,
numbered from one. It is a Match error if an led is specified without
an led-mode.
If both auto-repeat-mode and key are specified, then the auto-repeat
mode of that key is changed, if possible. If only auto-repeat-mode is
specified, then the global auto-repeat mode for the entire keyboard is
changed, if possible, without affecting the per-key settings. It is a
Match error if a key is specified without an auto-repeat-mode.
A bell generator connected with the console but not directly on the
keyboard is treated as if it were part of the keyboard.
The order in which controls are verified and altered is server
dependent. If an error is generated, a subset of the controls may have
been altered.
GetKeyboardControl
=>
key-click-percent: CARD8
bell-percent: CARD8
bell-pitch: CARD16
bell-duration: CARD16
led-mask: CARD32
global-auto-repeat: {On, Off}
auto-repeats: LISTofCARD8
Errors: Match
Returns the current control values for the keyboard. For the LEDs, the
least significant bit of led-mask corresponds to LED one, and each one
bit in led-mask indicates an LED that is lit. Auto-repeats is a bit
vector; each one bit indicates that auto-repeat is enabled for the
corresponding key. The vector is represented as 32 bytes. Byte N
(from 0) contains the bits for keys 8N to 8N+7, with the least
significant bit in the byte representing key 8N.
Bell
percent: INT8
Errors: Match, Value
Rings the bell on the keyboard at the specified volume relative to the
base volume for the keyboard, if possible. Percent, which can range
from -100 to 100 inclusive, is added to the base volume, and the sum
limited to the range 0 to 100 inclusive.
∂01-Jun-87 0527 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 1 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:27:21 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:26-EDT
Date: Mon, 1 Jun 87 08:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 1 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082645.6.RWS@KILLINGTON.LCS.MIT.EDU>
X WINDOW SYSTEM PROTOCOL, VERSION 11
Alpha Update
April 1987
Copyright (c) 1986, 1987 Massachusetts Institute of Technology
X Window System is a trademark of M.I.T.
Permission to use, copy, modify, and distribute this document for any purpose
and without fee is hereby granted, provided that the above copyright notice
appear in all copies and that both that copyright notice and this permission
notice are retained, and that the name of M.I.T. not be used in advertising or
publicity pertaining to this document without specific, written prior
permission. M.I.T. makes no representations about the suitability of this
document or the protocol defined in this document for any purpose. It is
provided "as is" without express or implied warranty.
Author: Robert W. Scheifler
Laboratory for Computer Science
545 Technology Square, Room 418
Cambridge, MA 02139
Contributors:
Dave Carver (Digital HPW)
Branko Gerovac (Digital HPW)
Jim Gettys (MIT/Project Athena, Digital)
Phil Karlton (Digital WSL)
Scott McGregor (Digital SSG)
Ram Rao (Digital UEG)
David Rosenthal (Sun)
Dave Winchell (Digital UEG)
Implementors of initial server who provided useful input:
Susan Angebranndt (Digital)
Raymond Drewry (Digital)
Todd Newman (Digital)
Invited reviewers who provided useful input:
Andrew Cherenson (Berkeley)
Burns Fisher (Digital)
Dan Garfinkel (HP)
Leo Hourvitz (Next)
Brock Krizan (HP)
David Laidlaw (Stellar)
Dave Mellinger (Interleaf)
Ron Newman (MIT)
John Ousterhout (Berkeley)
Andrew Palay (ITC CMU)
Ralph Swick (MIT)
Craig Taylor (Sun)
Jeffery Vroom (Stellar)
This document does not attempt to provide the rationale or pragmatics required
to fully understand the protocol or to place it in perspective within a
complete system. Knowledge of X Version 10 will certainly aid in
understanding this document.
The protocol contains many management mechanisms that are not intended for
normal applications. Not all mechanisms are needed to build a particular user
interface. It is important to keep in mind that the protocol is intended to
provide mechanism, not policy.
This document does not attempt to define precise formats or bit encodings.
-------------------------------------------------------------------------------
SECTION 1. TERMINOLOGY
Access control list
X maintains a list of hosts from which client programs may be run. By
default, only programs on the local host may use the display, plus any
hosts specified in an initial list read by the server. This "access
control list" can be changed by clients on the local host. Some server
implementations may also implement other authorization mechanisms.
Active grab
A grab is "active" when the pointer or keyboard is actually owned by
the single grabbing client.
Ancestors
If W is an inferior of A, then A is an "ancestor" of W.
Atom
An "atom" is a unique id corresponding to a string name. Atoms are
used to identify properties, types, and selections.
Backing store
When a server maintains the contents of a window, the off-screen saved
pixels are known as a "backing store".
Bit gravity
When a window is resized, the contents of the window are not
necessarily discarded. It is possible to request the server (though no
guarantees are made) to relocate the previous contents to some region
of the window. This attraction of window contents for some location of
a window is known as "bit gravity".
Bitmap
A "bitmap" is a pixmap of depth one.
Button grabbing
Buttons on the pointer may be passively "grabbed" by a client. When
the button is pressed, the pointer is then actively grabbed by the
client.
Byte order
For image (pixmap/bitmap) data, byte order is defined by the server,
and clients with different native byte ordering must swap bytes as
necessary. For all other parts of the protocol, the byte order is
defined by the client, and the server swaps bytes as necessary.
Children
The "children" of a window are its first-level subwindows.
Client
An application program connects to the window system server by some
interprocess communication (IPC) path, such as a TCP connection or a
shared memory buffer. This program is referred to as a "client" of the
window system server. More precisely, the client is the IPC path
itself; a program with multiple paths open to the server is viewed as
multiple clients by the protocol. Resource lifetimes are controlled by
connection lifetimes, not by program lifetimes.
Clipping regions
In a graphics context, a bitmap or list of rectangles can be specified
to restrict output to a particular region of the window. The image
defined by the bitmap or rectangles is called a "clipping region".
Color cell
An entry in a colormap is known as a "color cell". An entry contains
three values specifying red, green and blue intensities. These values
are always viewed as 16 bit unsigned numbers, with zero being minimum
intensity. The values are scaled by the server to match the display
hardware. The components of a cell are coincident with components of
other cells in DirectColor and TrueColor colormaps.
Colormap
A "colormap" consists of a set of color cells. A pixel value indexes
the color map to produce intensities to be displayed. Depending on
hardware limitations, one or more colormaps may be installed at one
time, such that windows associated with those maps display with true
colors.
Connection
The IPC path between the server and client program is known as a
"connection". A client program typically (but not necessarily) has one
connection to the server over which requests and events are sent.
Containment
A window "contains" the pointer if the window is viewable and the
hotspot of the cursor is within a visible region of the window or a
visible region of one of its inferiors. The border of the window is
included as part of the window for containment. The pointer is "in" a
window if the window contains the pointer but no inferior contains the
pointer.
Coordinate system
The coordinate system has X horizontal and Y vertical, with the origin
[0, 0] at the upper left. Coordinates are discrete, and in terms of
pixels. Each window and pixmap has its own coordinate system. For a
window, the origin is at the inside upper left, inside the border.
Cursor
A "cursor" is the visible shape of the pointer on a screen. It
consists of a hot spot, a source bitmap, a shape bitmap, and a pair of
colors. The cursor defined for a window controls the visible
appearance when the pointer is in that window.
Depth
The "depth" of a window or pixmap is number of bits per pixel it has.
The depth of a gcontext is the depth of the root of the gcontext.
Device
Keyboards, mice, tablets, track-balls, button boxes, etc. are all
collectively known as input "devices". The core protocol only deals
with two devices, "the keyboard" and "the pointer".
Drawable
Both windows and pixmaps may be used as sources and destinations in
graphics operations. These are collectively known as "drawables".
However, an InputOnly window cannot be used as a source or destination
in a graphics operation.
Event
Clients are informed of information asynchronously via "events". These
events may be either asynchronously generated from devices, or
generated as side effects of client requests. Events are grouped into
types; events are never sent to a client by the server unless the
client has specificially asked to be informed of that type of event,
but other clients can force events to be sent to other clients. Events
are typically reported relative to a window.
Event mask
Events are requested relative to a window. The set of event types a
client requests relative to a window described using an "event mask".
Event sychronization
There are certain race conditions possible when demultiplexing device
events to clients (in particular deciding where pointer and keyboard
events should be sent when in the middle of window management
operations). The event synchronization mechanism allows synchronous
processing of device events.
Event propagation
Device-related events "propagate" from the source window to ancestor
windows until some client has expressed interest in handling that type
of event, or until the event is discarded explicitly.
Event source
The smallest window containing the pointer is the "source" of a device
related event.
Exposure event
Servers do not guarantee to preserve the contents of windows when
windows are obscured or reconfigured. "Exposure" events are sent to
clients to inform them when contents of regions of windows have been
lost.
Extension
Named "extensions" to the core protocol can be defined to extend the
system. Extension to output requests, resources, and event types are
all possible, and expected.
Font
A "font" is an array of glyphs (typically characters). The protocol
does no translation or interpretation of character sets. The client
simply indicates values used to index the glyph array. A font contains
additional metric information to determine inter-glyph and inter-line
spacing.
Glyph
A "glyph" is an image, typically of a character, in a font.
Grab
Keyboard keys, the keyboard, pointer buttons, the pointer, and the
server can be "grabbed" for exclusive use by a client. In general,
these facilities are not intended to be used by normal applications,
but are intended for various input and window managers to implement
various styles of user interfaces.
Graphics context
Various information for graphics output is stored in "GC"'s, such as
foreground pixel, background pixel, line width, clipping region, etc.
Hotspot
A cursor has an associated "hot spot" which defines a point in the
cursor that corresponds to the coordinates reported for the pointer.
Identifier
Each resource has an "identifier", a unique value associated with it
that clients use to name the resource. An identifier can be used over
any connection to name the resource.
Inferiors
The "inferiors" of a window are all of the subwindows nested below it:
the children, the children's children, etc.
Input focus
The "input focus" is nominally where keyboard input goes. Keyboard
events are by default sent to the client expressing interest on the
window the pointer is in. This is said to be a "real estate driven"
input focus. It is also possible to attach the keyboard input to a
specific window; events will then be sent to the appropriate client
independent of the pointer position.
Input manager
Control over keyboard input is typically provided by an "input manager"
client.
InputOnly window
A window that cannot be used for graphics requests. InputOnly windows
are "invisible", and can be used to control such things as cursors,
input event generation, and grabbing.
InputOutput window
The "normal" kind of opaque window, used for both input and output.
Key grabbing
Keys on the keyboard may be passively "grabbed" by a client. When the
key is pressed, the keyboard is then actively grabbed by the client.
Keyboard grabbing
A client can actively "grab" control of the keyboard, and key events
will be sent to that client rather than the client the events would
normally have been sent to.
Mapping
A window is said to be "mapped" if a map call has been performed on it.
Unmapped windows are never viewable or visible.
Modifier keys
Shift, Control, Meta, Super, Hyper, ALT, Compose, Apple, CapsLock,
ShiftLock, and similar keys are called "modifier" keys.
Obscures
Window A "obscures" window B if both are viewable InputOutput windows
and A is higher in the global stacking order, and the rectangle defined
by the outside edges of A intersects the rectangle defined by the
outside edges of B. Note the (fine) distinction with "occludes". Also
note that window borders are included in the calculation.
Occludes
Window A "occludes" window B if both are mapped and A is higher in the
global stacking order, and the rectangle defined by the outside edges
of A intersects the rectangle defined by the outside edges of B. Note
the (fine) distinction with "obscures". Also note that window borders
are included in the calculation.
Padding
Some padding bytes are inserted in the data stream to maintain
alignment of the protocol requests on natural boundaries. This
increases ease of portability to some machine architectures.
Parent window
If C is a child of P, then P is the "parent" of C.
Passive grab
Grabbing a key or button is a "passive" grab. The grab activates when
the key or button is actually pressed.
Pixel value
A "pixel" is an N-bit value, where N is the number of bit planes used
in a particular window or pixmap. For a window, a pixel value indexes
a colormap to derive an actual color to be displayed.
Pixmap
A "pixmap" is a three dimensional array of bits. A pixmap is normally
thought of as a two dimensional array of pixels, where each pixel can
be a value from 0 to (2↑N)-1, where N is the depth (z axis) of the
pixmap. A pixmap can also be thought of as a stack of N bitmaps.
Plane mask
Graphics operations can be restricted to only affect a subset of bit
planes of a destination. A "plane mask" is a bit mask describing which
planes are to be modified, and is stored in a graphics context.
Pointer
The "pointer" is the pointing device attached to the cursor, and
tracked on the screens.
Pointer grabbing
A client can actively "grab" control of the pointer, and button and
motion events will be sent to that client rather than the client the
events would normally have been sent to.
Pointing device
A "pointing device" is typically a mouse or tablet, or some other
device with effective dimensional motion. There is only one visible
cursor is defined by the core protocol, and it tracks whatever pointing
device is attached as the pointer.
Property
Windows may have associated "properties", consisting of a name, a type,
a data format, and some data. The protocol places no interpretation on
properties, they are intended as a general-purpose naming mechanism for
clients. For example, clients might share information such as resize
hints, program names, and icon formats with a window manager via
properties.
Property list
The "property list" of a window is the list of properties that have
been defined for the window.
Redirecting control
Window managers (or client programs) may wish to enforce window layout
policy in various ways. When a client attempts to change the size or
position of a window, the operation may be "redirected" to a specified
client, rather than the operation actually being performed.
Reply
Information requested by a client program is sent back to the client
with a "reply". Both events and replys are multipexed on the same
connection. Most requests do not generate replies.
Request
A command to the server is called a "request". It is a single block of
data sent over a connection.
Resource
Windows, pixmaps, cursors, fonts, graphics contexts, and colormaps are
known as "resources". They all have unique identifiers associated with
them for naming purposes. The lifetime of a resource is bounded by the
lifetime of the connection over which the resource was created.
Root
The "root" of a pixmap or gcontext is the same as the root of whatever
drawable was used when the pixmap or gcontext was created. The "root"
of a window is the root window under which the window was created.
Root window
Each screen has a "root window" covering it. It cannot be reconfigured
or unmapped, but otherwise acts as a full fledged window. A root
window has no parent.
Save set
The "save set" of a client is a list of other client's windows which,
if they are inferiors of one of the client's windows at connection
close, should not be destroyed, and which should be remapped if it is
unmapped. Save sets are typically used by window managers to avoid
lost windows if the manager should terminate abnormally.
Screen
A server may provide several independent "screens", which typically
have physically independent monitors. This would be the expected
configuration when there is only a single keyboard and pointer shared
among the screens.
Server
The "server" provides the basic windowing mechanism. It handles IPC
connections from clients, demultipexes graphics requests onto the
screens, and multiplexes input back to the appropriate clients.
Server grabbing
The server can be "grabbed" by a single client for exclusive use. This
prevents processing of any requests from other client connections until
the grab is complete. This is typically only a transient state for
such things as rubber-banding and pop-up menus, or to execute requests
indivisibly.
Sibling
Children of the same parent window are known as "sibling" windows.
Stacking order
Sibling windows may "stack" on top of each other. Windows above both
obscure and occlude lower windows. This is similar to paper on a desk.
The relationship between sibling windows is known as the "stacking
order".
Stipple
A "stipple pattern" is a bitmap that is used to tile a region to serve
as an additional clip mask for a fill operation with the foreground
color.
Tile
A pixmap can be replicated in two dimensions to "tile" a region. The
pixmap itself is also known as a "tile".
Timestamp
A time value, expressed in milliseconds, typically since the last
server reset. Timestamp values wrap around (after about 49.7 days).
The server, given its current time is represented by timestamp T,
always interprets timestamps from clients by treating half of the
timestamp space as being earlier in time than T, and half of the
timestamp space as being later in time than T. One timestamp value
(named CurrentTime) is never generated by the server; this value is
reserved for use in requests to represent the current server time.
Type
A type is an arbitrary atom used to identify the interpretation of
property data. Types are completely uninterpreted by the server; they
are solely for the benefit of clients.
Unviewable
A window is "unviewable" if it is mapped but some ancestor is unmapped.
Viewable
A window is "viewable" if it and all of its ancestors are mapped. This
does not imply that any portion of the window is actually visible.
Visible
A region of a window is "visible" if someone looking at the screen can
actually "see" it: the window is viewable and the region is not
occluded by any other window.
Window gravity
When windows are resized, subwindows may be repositioned automatically
relative to some position in the window. This attraction of a
subwindow to some part of its parent is known as "window gravity".
Window manager
Manipulation of windows on the screen, and much of the user interface
(policy) is typically provided by a "window manager" client.
XYFormat
The data for a pixmap is said to be in "XYFormat" if it is organized as
a set of bitmaps representing individual bit planes.
ZFormat
The data for a pixmap is said to be in "ZFormat" if it is organized as
a set of pixel values in scanline order.
SECTION 2. PROTOCOL FORMATS
Request Format
Every request contains an 8-bit "major" opcode, and a 16-bit length field
expressed in units of 4 bytes. Every request consists of 4 bytes of header
(containing the major opcode, the length field, and a data byte) followed by
zero or more additional bytes of data; the length field defines the total
length of the request, including the header. The length field in a request
must equal the minimum length required to contain the request; if the
specified length is smaller or larger than the required length, an error is
generated. Unused bytes in a request are not required to be zero. Major
opcodes 128 through 255 are reserved for extensions. Extensions are intended
to contain multiple requests, so extension requests typically have an
additional minor opcode encoded in the "spare" data byte in the request
header, but the placement and interpretation of this minor opcode, and all
other fields in extension requests, are not defined by the core protocol.
Every request is implicitly assigned a sequence number, starting with one,
used in replies, errors, and events.
Reply Format
Every reply contains a 32-bit length field expressed in units of 4 bytes.
Every reply consists of 32 bytes, followed by zero or more additional bytes of
data, as specified in the length field. Unused bytes within a reply are not
guaranteed to be zero. Every reply also contains the least significant 16
bits of the sequence number of the corresponding request.
Error Format
Error reports are 32 bytes long. Every error includes an 8-bit error code.
Error codes 128 through 255 are reserved for extensions. Every error also
includes the major and minor opcodes of the failed request, and the least
significant 16 bits of the sequence number of the request. For the following
errors (see Section 5), the failing resource id is also returned: Colormap,
Cursor, Drawable, Font, GContext, IDChoice, Pixmap, and Window. For Atom
errors, the failing atom is returned. For Value errors, the failing value is
returned. Other core errors return no additional data. Unused bytes within
an error are not guaranteed to be zero.
Event Format
Events are 32 bytes long. Unused bytes within an event are not guaranteed to
be zero. Every event contains an 8-bit type code. The most significant bit
in this code is set if the event was generated from a SendEvent request.
Event codes 64 through 127 are reserved for extensions, although the core
protocol does not define a mechanism for selecting interest in such events.
Every core event (with the exception of KeymapNotify) also contains the least
significant 16 bits of the sequence number of the last request issued by the
client that was (or is currently being) processed by the server.
SECTION 3. SYNTAX
The syntax {...} encloses a set of alternatives.
The syntax [...] encloses a set of structure components.
In general, TYPEs are in upper case and AlternativeValues are capitalized.
Requests in Section 10 are described in the following format:
RequestName
arg1: type1
...
argN: typeN
=>
result1: type1
...
resultM: typeM
Errors: kind1, ..., kindK
Description.
If no => is present in the description, then the request has no reply (it is
asynchronous), although errors may still be reported.
Events in Section 12 are described in the following format:
EventName
value1: type1
...
valueN: typeN
Description.
SECTION 4. COMMON TYPES
LISTofFOO
A type name of the form LISTofFOO means a counted list of elements of type
FOO; the size of the length field may vary (it is not necessarily the same
size as a FOO), in some cases may be implicit, and is not fully specified in
this document.
BITMASK and LISTofVALUE
The types BITMASK and LISTofVALUE are somewhat special. Various requests
contain arguments of the form:
value-mask: BITMASK
value-list: LISTofVALUE
used to allow the client to specify a subset of a heterogeneous collection of
"optional" arguments. The value-mask specifies which arguments are to be
provided; each such argument is assigned a unique bit position. The
representation of the BITMASK will typically contain more bits than there are
defined arguments; unused bits in the value-mask must be zero (or the server
generates a Value error). The value-list contains one value for each one bit
in the mask, from least to most significant bit in the mask. Each value is
represented with 4 bytes, but the actual value occupies only the least
significant bytes as required; the values of the unused bytes do not matter.
Or Types
A type of the form "T1 or ... or Tn" means the union of the indicated types; a
single-element type is given as the element without enclosing braces.
DEVICE: 32-bit id (<class,model,manufacturer,unit> 8 bits each)
WINDOW: 32-bit id
PIXMAP: 32-bit id
CURSOR: 32-bit id
FONT: 32-bit id
GCONTEXT: 32-bit id
COLORMAP: 32-bit id
DRAWABLE: WINDOW or PIXMAP
ATOM: 32-bit id (top 3 bits guaranteed to be zero)
VISUALID: 32-bit id (top 3 bits guaranteed to be zero)
VALUE: 32-bit quantity (used only in LISTofVALUE)
INT8: 8-bit signed integer
INT16: 16-bit signed integer
INT32: 32-bit signed integer
CARD8: 8-bit unsigned integer
CARD16: 16-bit unsigned integer
CARD32: 32-bit unsigned integer
TIMESTAMP: CARD32
BITGRAVITY: {Forget, Static,
NorthWest, North, NorthEast,
West, Center, East,
SouthWest, South, SouthEast}
WINGRAVITY: {Unmap, Static,
NorthWest, North, NorthEast,
West, Center, East,
SouthWest, South, SouthEast}
BOOL: {True, False}
EVENT: {KeyPress, KeyRelease,
OwnerGrabButton,
ButtonPress, ButtonRelease, EnterWindow, LeaveWindow,
PointerMotion, PointerMotionHint,
Button1Motion, Button2Motion, Button3Motion,
Button4Motion, Button5Motion, ButtonMotion
Exposure, VisibilityChange,
StructureNotify, ResizeRedirect,
SubstructureNotify, SubstructureRedirect,
FocusChange,
PropertyChange, ColormapChange,
KeymapState}
POINTEREVENT: {ButtonPress, ButtonRelease, EnterWindow, LeaveWindow,
PointerMotion, PointerMotionHint,
Button1Motion, Button2Motion, Button3Motion,
Button4Motion, Button5Motion, ButtonMotion
KeymapState}
DEVICEEVENT: {KeyPress, KeyRelease,
ButtonPress, ButtonRelease,
PointerMotion,
Button1Motion, Button2Motion, Button3Motion,
Button4Motion, Button5Motion, ButtonMotion}
KEYCODE: CARD8
BUTTON: CARD8
KEYMASK: {Shift, CapsLock, Control, Mod1, Mod2, Mod3, Mod4, Mod5}
BUTMASK: {Button1, Button2, Button3, Button4, Button5}
KEYBUTMASK: KEYMASK or BUTMASK
STRING8: LISTofCARD8
STRING16: LISTofCHAR2B
CHAR2B: [byte1, byte2: CARD8]
POINT: [x, y: INT16]
RECTANGLE: [x, y: INT16,
width, height: CARD16]
ARC: [x, y: INT16,
width, height: CARD16,
angle1, angle2: INT16]
HOST: [family: {Internet, NS, ECMA, Datakit, DECnet}
address: LISTofCARD8]
The [x,y] coordinates of a RECTANGLE specify the upper left corner.
The primary interpretation of "large" characters in a STRING16 is that they
are composed of two bytes used to index a 2-D matrix; hence the use of CHAR2B
rather than CARD16. This corresponds to the JIS/ISO method of indexing
two-byte characters. It is expected that most "large" fonts will be defined
with two-byte matrix indexing. For large fonts constructed with linear
indexing, a CHAR2B can be interpreted as a 16-bit number by treating byte1 as
the most significant byte; this means that clients should always transmit such
16-bit character values most significant byte first, as the server will never
byte-swap CHAR2B quantities.
The length, format, and interpretation of a HOST address are specific to the
family.
SECTION 5. ERRORS
In general, when a request terminates with an error, the request has no side
effects (i.e., there is no partial execution). The only requests for which
this is not true are ChangeWindowAttributes, ChangeGC, PolyText8, PolyText16,
FreeColors, StoreColors, and ChangeKeyboardControl.
The following error codes can be returned by the various requests:
Access
An attempt to grab a key/button combination already grabbed by another
client.
An attempt to free a colormap entry not allocated by the client.
An attempt to store into a read-only or an unallocated colormap entry.
An attempt to modify the access control list from other than the local
(or otherwise authorized) host.
An attempt to select an event type, that at most one client can
select at a time, when another client has already selected it.
Alloc
The server failed to allocate the requested resource.
Note that this only covers allocation errors at a very coarse level,
and is not intended to (nor can it in practice hope to) cover all cases
of a server running out of allocation space in the middle of service.
The semantics when a server runs out of allocation space are left
unspecified.
Atom
A value for an ATOM argument does not name a defined ATOM.
Colormap
A value for a COLORMAP argument does not name a defined COLORMAP.
Cursor
A value for a CURSOR argument does not name a defined CURSOR.
Drawable
A value for a DRAWABLE argument does not name a defined WINDOW or
PIXMAP.
Font
A value for a FONT or <FONT or GCONTEXT> argument does not name a
defined FONT.
GContext
A value for a GCONTEXT argument does not name a defined GCONTEXT.
IDChoice
The value chosen for a resource identifier is either not included
in the range assigned to the client, or is already in use.
Implementation
The server does not implement some aspect of the request. A server
which generates this error for a core request is deficient. As such,
this error is not listed for any of the requests, but clients should be
prepared to receive such errors, and handle or discard them.
Length
The length of a request is shorter or longer than that required
to minimally contain the arguments.
Match
An InputOnly window is used as a DRAWABLE.
Some argument (or pair of arguments) has the correct type and range,
but fails to "match" in some other way required by the request.
Name
A font or color of the specified name does not exist.
Pixmap
A value for a PIXMAP argument does not name a defined PIXMAP.
Property
The requested property does not exist for the specified window.
Request
The major or minor opcode does not specify a valid request.
Value
Some numeric value falls outside the range of values accepted by the
request. Unless a specific range is specified for an argument, the
full range defined by the argument's type is accepted. Any argument
defined as a set of alternatives can generate this error.
Window
A value for a WINDOW argument does not name a defined WINDOW.
Note: the Atom, Colormap, Cursor, Drawable, Font, GContext, Pixmap, and Window
errors are also used when the argument type is extended by union with a set of
fixed alternatives, e.g., <Window or PointerRoot or None>.
∂01-Jun-87 0529 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 4 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:28:53 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:27-EDT
Date: Mon, 1 Jun 87 08:28 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 4 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082815.9.RWS@KILLINGTON.LCS.MIT.EDU>
QueryFont
font: FONT or GCONTEXT
=>
font-info: FONTINFO
char-infos: LISTofCHARINFO
where
FONTINFO: [draw-direction: {LeftToRight, RightToLeft}
min-char-or-byte2, max-char-or-byte2: CARD16
min-byte1, max-byte1: CARD8
all-chars-exist: BOOL
default-char: CARD16
min-bounds: CHARINFO
max-bounds: CHARINFO
font-ascent: INT16
font-descent: INT16
properties: LISTofFONTPROP]
FONTPROP: [name: ATOM
value: INT32 or CARD32]
CHARINFO: [left-side-bearing: INT16
right-side-bearing: INT16
character-width: INT16
ascent: INT16
descent: INT16
attributes: CARD16]
Errors: Font
Returns logical information about a font.
The draw-direction is essentially just a hint, indicating whether most
char-infos have a positive (LeftToRight) or a negative (RightToLeft)
character-width metric. The core protocol defines no support for
vertical text.
If min-byte1 and max-byte1 are both zero, then min-char-or-byte2
specifies the linear character index corresponding to the first elementb
of char-infos, and max-char-or-byte2 specifies the linear character
index of the last element. If either min-byte1 or max-byte1 are
non-zero, then both min-char-or-byte2 and max-char-or-byte2 will be
less than 256, and the two-byte character index values corresponding to
char-infos element N (counting from 0) are
byte1 = N/D + min-byte1
byte2 = N\D + min-char-or-byte2
where
D = max-char-or-byte2 - min-char-or-byte2 + 1
/ = integer division
\ = integer modulus
If char-infos has length zero, then min-bounds and max-bounds will be
identical, and the effective char-infos is one filled with this
char-info, of length
L = D * (max-byte1 - min-byte1 + 1)
That is, all glyphs in the specified linear or matrix range have the
same information, as given by min-bounds (and max-bounds). If
all-chars-exist is True, then all characters in char-infos have
non-zero bounding boxes.
The default-char specifies the character that will be used when an
undefined or non-existent character is used. Note that default-char is
a CARD16 (not CHAR2B); for a font using two-byte matrix format, the
default-char has byte1 in the most significant byte, and byte2 in the
least significant byte. If the default-char itself specifies an
undefined or non-existent character, then no printing is performed for
an undefined or non-existent character.
The min-bounds and max-bounds contain the minimum and maximum values of
each individual CHARINFO component over all char-infos (ignoring
non-existent characters). The bounding box of the font, i.e., the
smallest rectangle enclosing the shape obtained by superimposing all
characters at the same origin [x,y], has its upper left coordinate at
[x + min-bounds.left-side-bearing, y - max-bounds.ascent]
with a width of
max-bounds.right-side-bearing - min-bounds.left-side-bearing
and a height of
max-bounds.ascent + max-bounds.descent
The font-ascent is the logical extent of the font above the baseline,
for determining line spacing. Specific characters may extend beyond
this. The font-descent is the logical extent of the font at or below
the baseline, for determining line spacing. Specific characters may
extend beyond this. If the baseline is at Y-coordinate y, then the
logical extent of the font is inclusive between the Y-coordinate values
(y - font-ascent) and (y + font-descent - 1).
A font is not guaranteed to have any properties. Whether a property
value is signed or unsigned must be derived from a priori knowledge of
the property. When possible, fonts should have at least the following
properties (note that the trailing colon is not part of the name, and
that upper/lower case matters).
MinSpace: CARD32
The minimum interword spacing, in pixels.
NormSpace: CARD32
The normal interword spacing, in pixels.
MaxSpace: CARD32
The maximum interword spacing, in pixels.
EndSpace: CARD32
The additional spacing at the end of sentences, in pixels.
SuperscriptX: INT32
SuperscriptY: INT32
Offsets from the character origin where superscripts should begin,
in pixels. If the origin is at [x,y], then superscripts should
begin at [x + SuperscriptX, y - SuperscriptY].
SubscriptX: INT32
SubscriptY: INT32
Offsets from the character origin where subscripts should begin, in
pixels. If the origin is at [x,y], then subscripts should begin at
[x + SubscriptX, y + SubscriptY].
UnderlinePosition: INT32
Y offset from the baseline to the top of an underline, in pixels.
If the baseline is Y-coordinate y, then the top of the underline is
at (y + UnderlinePosition).
UnderlineThickness: CARD32
Thickness of the underline, in pixels.
StrikeoutAscent: INT32
StrikeoutDescent: INT32
Vertical extents for boxing or voiding characters, in pixels. If
the baseline is at Y-coordinate y, then the top of the strikeout
box is at (y - StrikeoutAscent), and the height of the box is
(StrikeoutAscent + StrikeoutDescent).
ItalicAngle: INT32
The angle of characters in the font, in degrees scaled by 64,
relative to the three-oclock position from the character origin,
with positive indicating counterclockwise motion (as in Arc
requests).
XHeight: INT32
"1 ex" as in TeX, but expressed in units of pixels. Often the
height of lowercase x.
QuadWidth: INT32
"1 em" as in TeX, but expressed in units of pixels. Often the
width of the digits 0-9.
Weight: CARD32
The weight or boldness of the font, expressed as a value between 0
and 1000.
PointSize: CARD32
The point size, expressed in 1/10ths, of this font at the ideal
resolution. There are 72.27 points to the inch.
Resolution: CARD32
The number of pixels per point, expressed in 1/100ths, at which
this font was created.
For a character origin at [x,y], the bounding box of a character, i.e.,
the smallest rectangle enclosing the character's shape, described in
terms of CHARINFO components, is a rectangle with its upper left corner
at
[x + left-side-bearing, y - ascent]
with a width of
right-side-bearing - left-side-bearing
and a height of
ascent + descent
and the origin for the next character is defined to be
[x + character-width, y]
Note that the baseline is logically viewed as being just below
non-descending characters (when descent is zero, only pixels with
Y-coordinates less than y are drawn), and that the origin is logically
viewed as being coincident with the left edge of a non-kerned character
(when left-side-bearing is zero, no pixels with X-coordinate less than
x are drawn).
Note that CHARINFO metric values can be negative.
A non-existent character is represented with all CHARINFO components
zero.
The interpretation of the per-character attributes field is undefined
by the core protocol.
QueryTextExtents
font: FONT or GCONTEXT
items: STRING16
=>
draw-direction: {LeftToRight, RightToLeft}
font-ascent: INT16
font-descent: INT16
overall-ascent: INT16
overall-descent: INT16
overall-width: INT32
overall-left: INT32
overall-right: INT32
Errors: Font
Returns the logical extents of the specified string of characters in
the specified font. Draw-direction, font-ascent, and font-descent are
as described in QueryFont. Overall-ascent is the maximum of the ascent
metrics of all characters in the string, and overall-descent is the
maximum of the descent metrics. Overall-width is the sum of the
character-width metrics of all characters in the string. For each
character in the string, let W be the sum of the character-width
metrics of all characters preceding it in the string, let L be the
left-side-bearing metric of the character plus W, and let R be the
right-side-bearing metric of the character plus W. Overall-left is the
minimum L of all characters in the string, and overall-right is the
maximum R.
For fonts defined with linear indexing rather than two-byte matrix
indexing, the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (i.e., byte1 of the
CHAR2B is taken as the most significant byte).
If the font has no defined default-char, then undefined characters in
the string are taken to have all zero metrics.
ListFonts
pattern: STRING8
max-names: CARD16
=>
names: LISTofSTRING8
Returns a list of length at most max-names, of names of fonts matching
the pattern. The pattern should use the ASCII encoding, and
upper/lower case does not matter. In the pattern, the '?' character
(octal value 77) will match any single character, and the character '*'
(octal value 52) will match any number of characters. The returned
names are in lower case.
ListFontsWithInfo
pattern: STRING8
max-names: CARD16
=>
fonts: LISTofFONTDATA
where
FONTDATA: [name: STRING8
info: FONTINFO]
FONTINFO: <same type definition as in QueryFont>
Like ListFonts, but also returns information about each font. The
information returned for each font is identical to what QueryFont would
return (except that the per-character metrics are not returned).
SetFontPath
path: LISTofSTRING8
Errors: Value
Defines the search path for font lookup. There is only one search path
per server, not one per client. The interpretation of the strings is
operating system dependent, but they are intended to specify
directories to be searched in the order listed.
Setting the path to the empty list restores the default path defined
for the server.
As a side-effect of executing this request, the server is guaranteed to
flush all cached information about fonts for which there currently are
no explicit resource ids allocated.
The meaning of an error from this request is system specific.
GetFontPath
=>
path: LISTofSTRING8
Returns the current search path for fonts.
CreatePixmap
pid: PIXMAP
drawable: DRAWABLE
depth: CARD8
width, height: CARD16
Errors: IDChoice, Drawable, Value, Alloc
Creates a pixmap, and assigns the identifier pid to it. Width and
height must be non-zero. Depth must be one of the depths supported by
root of the specified drawable. The initial contents of the pixmap are
undefined.
It is legal to pass an InputOnly window as a drawable to this request.
FreePixmap
pixmap: PIXMAP
Errors: Pixmap
Deletes the association between the resource id and the pixmap. The
pixmap storage will be freed when no other resource references it.
CreateGC
cid: GCONTEXT
drawable: DRAWABLE
value-mask: BITMASK
value-list: LISTofVALUE
Errors: IDChoice, Drawable, Pixmap, Font, Match, Value, Alloc
Creates a graphics context, and assigns the identifier cid to it. The
gcontext can be used with any destination drawable having the same root
and depth as the specified drawable.
The value-mask and value-list specify which components are to be
explicitly initialized. The context components are:
alu-function: {Clear, And, AndReverse, Copy, AndInverted, Noop,
Xor, Or, Nor, Equiv, Invert, OrReverse,
CopyInverted, OrInverted, Nand, Set}
plane-mask: CARD32
foreground: CARD32
background: CARD32
line-width: CARD16
line-style: {Solid, OnOffDash, DoubleDash}
cap-style: {NotLast, Butt, Round, Projecting}
join-style: {Miter, Round, Bevel}
fill-style: {Solid, Tiled, OpaqueStippled, Stippled}
fill-rule: {EvenOdd, Winding}
arc-mode: {Chord, PieSlice}
tile: PIXMAP
stipple: PIXMAP
tile-stipple-x-origin: INT16
tile-stipple-y-origin: INT16
font: FONT
subwindow-mode: {ClipByChildren, IncludeInferiors}
graphics-exposures: BOOL
clip-x-origin: INT16
clip-y-origin: INT16
clip-mask: PIXMAP or None
dash-offset: CARD16
dash-list: CARD8
In graphics operations, given a source and destination pixel, the
result is computed bitwise on corresponding bits of the pixels. That
is, a boolean operation is performed in each bit plane. The plane-mask
restricts the operation to a subset of planes. That is, the result is
((src FUNC dst) AND plane-mask) OR (dst AND (NOT plane-mask))
Range checking is not performed on the values for foreground,
background, or plane-mask; they are simply truncated to the appropriate
number of bits.
The meanings of the alu-functions are:
Clear 0
And src AND dst
AndReverse src AND (NOT dst)
Copy src
AndInverted (NOT src) AND dst
NoOp dst
Xor src XOR dst
Or src OR dst
Nor (NOT src) AND (NOT dst)
Equiv (NOT src) XOR dst
Invert NOT dst
OrReverse src OR (NOT dst)
CopyInverted NOT src
OrInverted (NOT src) OR dst
NAnd (NOT src) OR (NOT dst)
Set 1
Line-width is measured in pixels and can be greater than or equal to
one (a "wide" line) or the special value zero (a "thin" line).
Wide lines are drawn centered on the path described by the graphics
request. Unless otherwise specified by the join or cap style, the
bounding box of a wide line with endpoints [x1, y1], [x2, y2], and
width w is a rectangle with vertices at the following real coordinates:
[x1-(w*sn/2), y1+(w*cs/2)], [x1+(w*sn/2), y1-(w*cs/2)],
[x2-(w*sn/2), y2+(w*cs/2)], [x2+(w*sn/2), y2-(w*cs/2)]
where sn is the sine of the angle of the line and cs is the cosine of
the angle of the line. A pixel is part of the line (and hence drawn)
if the center of the pixel is fully inside the bounding box (which is
viewed as having infinitely thin edges). If the center of the pixel is
exactly on the bounding box, it is part of the line if and only if the
interior is immediately to its right (x increasing direction). Pixels
with centers on a horizontal edge are a special case and are part of
the line if and only if the interior is immediately below (y increasing
direction). Note that this description is a mathematical model
describing the pixels that are drawn for a wide line and does not imply
that trigonometry is required to implement such a model. Real or fixed
point arithmetic is recommended for computing the corners of the line
endpoints for lines greater than one pixel in width.
Thin lines (zero line-width) are "one pixel wide" lines drawn using an
unspecified, device dependent algorithm (for example, Bresenham).
There are only two constraints on this algorithm. First, if a line is
drawn unclipped from [x1,y1] to [x2,y2] and another line is drawn
unclipped from [x1+dx,y1+dy] to [x2+dx,y2+dy], then a point [x,y] is
touched by drawing the first line if and only if the point [x+dx,y+dy]
is touched by drawing the second line. Second, the effective set of
points comprising a line cannot be affected by clipping; that is, a
point is touched in a clipped line if and only if the point lies inside
the clipping region and the point would be touched by the line when
drawn unclipped.
Note that a wide line drawn from [x1,y1] to [x2,y2] always draws the
same pixels as a wide line drawn from [x2,y2] to [x1,y1], not counting
cap and join styles, but this property is not guaranteed for thin
lines. Also note that "jags" in adjacent wide lines will always line
up properly, but this property is not guaranteed for thin lines. A
line-width of zero differs from a line-width of one in which pixels are
drawn. In general, drawing a thin line will be faster than drawing a
wide line of width one, but thin lines may not mix well aesthetically
with wide lines because of the different drawing algorithms. If it is
desirable to obtain precise and uniform results across all displays, a
client should always use a line-width of one, rather than a line-width
of zero.
The line-style defines which segments of a line are drawn:
Solid: the full path of the line is drawn
DoubleDash: the full path of the line is drawn, but the segments
defined by the even dashes are filled differently than
the segments defined by the odd dashes (see fill-style)
OnOffDash: only the segments defined by the even dashes are drawn,
and cap-style applies to each individual segment (except
NotLast is treated as Butt for internal caps)
The cap-style defines how the endpoints of a path are drawn:
NotLast: equivalent to Butt, except that for a line-width
of zero or one the final endpoint is not drawn
Butt: square at the endpoint, with no projection beyond
Round: a circular arc with diameter equal to the line-width,
centered on the endpoint; equivalent to Butt for line-width
zero or one
Projecting: square at the end, but the path continues beyond the
endpoint for a distance equal to half the line-width;
equivalent to Butt for line-width zero or one
The join-style defines how corners are drawn for wide lines:
Miter: the outer edges of the two lines extend to meet at an
angle
Round: a circular arc with diameter equal to the line-width,
centered on the joinpoint
Bevel: Butt endpoint styles, and then the triangular "notch" filled
The tile/stipple and clip origins are interpreted relative to the
origin of whatever destination drawable is specified in a graphics
request.
The tile pixmap must have the same root and depth as the gcontext (else
a Match error). The stipple pixmap must have depth one, and must have
the same root as the gcontext (else a Match error). For stipple
operations, the stipple pattern is tiled in a single plane, and acts as
an additional clip mask to be ANDed with the clip-mask. Any size
pixmap can be used for tiling or stippling, although some sizes may be
faster to use than others.
The fill-style defines the contents of the source for line, text, and
fill requests. For all text and fill requests (PolyText8, PolyText16,
PolyFillRectangle, FillPoly, PolyFillArc), for line requests (PolyLine,
PolySegment, PolyRectangle, PolyArc) with line-style Solid, and for the
even dashes for line requests with line-style OnOffDash or DoubleDash:
Solid: foreground
Tiled: tile
OpaqueStippled: a tile with the same width and height as stipple,
but with background everywhere stipple has a zero
and with foreground everywhere stipple has a one
Stippled: foreground masked by stipple
For the odd dashes for line requests with line-style DoubleDash:
Solid: background
Tiled: same as for even dashes
OpaqueStippled: same as for even dashes
Stippled: background masked by stipple
The dash-list value allowed here is actually a simplified form of the
more general patterns that can be set with SetDashes. Specifying a
value of N here is equivalent to specifying the two element list [N, N]
in SetDashes. The value must be non-zero. The meaning of dash-offset
and dash-list are explained in the SetDashes request.
The clip-mask restricts writes to the destination drawable; only pixels
where the clip-mask has a one bit are drawn. It affects all graphics
requests. The clip-mask does not clip sources. The clip-mask origin
is interpreted relative to the origin of whatever destination drawable
is specified in a graphics request. If a pixmap is specified as the
clip-mask, it must have depth one and have the same root as the
gcontext (else a Match error). The clip-mask can also be set with the
SetClipRectangles request.
For ClipByChildren, both source and destination windows are
additionally clipped by all viewable InputOutput children. For
IncludeInferiors, neither source nor destination window is clipped by
inferiors; this will result in drawing through subwindow boundaries.
The use of IncludeInferiors on a window of one depth with mapped
inferiors of differing depth is not illegal, but the semantics is
undefined by the core protocol.
The fill-rule defines what pixels are inside (i.e., are drawn) for
paths given in FillPoly requests. EvenOdd means a point is inside if
an infinite ray with the point as origin crosses the path an odd number
of times. For Winding, a point is inside if an infinite ray with the
point as origin crosses an unequal number of clockwise and
counterclockwise directed path segments. For both rules, a "point" is
infinitely small, and the path is an infinitely thin line. A pixel is
inside if the center point of the pixel is inside and the center point
is not on the boundary. If the center point is on the boundary, the
pixel is inside if and only if the polygon interior is immediately to
its right (x increasing direction). Pixels with centers along a
horizontal edge are a special case and are inside if and only if the
polygon interior is immediately below (y increasing direction).
The arc-mode controls filling in the PolyFillArc request.
The graphics-exposures flag controls GraphicsExposure event generation
for CopyArea and CopyPlane requests (and any similar requests defined
by extensions).
The default component values are:
function: Copy
plane-mask: all ones
foreground: 0
background: 1
line-width: 0
line-style: Solid
cap-style: Butt
join-style: Miter
fill-style: Solid
full-rule: EvenOdd
arc-mode: PieSlice
tile: pixmap of unspecified size filled with foreground pixel
(i.e., client specified pixel if any, else 0)
stipple: pixmap of unspecified size filled with ones
tile-stipple-x-origin: 0
tile-stipple-y-origin: 0
font: <implementation dependent>
subwindow-mode: ClipByChildren
graphics-exposures: True
clip-x-origin: 0
clip-y-origin: 0
clip-mask: None
dash-offset: 0
dash-list: 4 (i.e., the list [4, 4])
Storing a pixmap in a gcontext might or might not result in a copy
being made. If the pixmap is later used as the destination for a
graphics request, the change might or might not be reflected in the
gcontext. If the pixmap is used simultaneously in a graphics request
as both a destination and as a tile or stipple, the results are not
defined.
It is quite likely that some amount of gcontext information will be
cached in display hardware, and that such hardware can only cache a
small number of gcontexts. Given the number and complexity of
components, clients should view switching between gcontexts with nearly
identical state as significantly more expensive than making minor
changes to a single gcontext.
ChangeGC
gc: GCONTEXT
value-mask: BITMASK
value-list: LISTofVALUE
Errors: GContext, Pixmap, Font, Match, Value, Alloc
Changes components in gc. The value-mask and value-list specify which
components are to be changed. The values and restrictions are the same
as for CreateGC.
Changing the clip-mask also overrides any previous SetClipRectangles
request on the context. Changing the dash-offset or dash-list
overrides any previous SetDashes request on the context.
The order in which components are verified and altered is server
dependent. If an error is generated, a subset of the components may
have been altered.
CopyGC
src-gc, dst-gc: GCONTEXT
value-mask: BITMASK
Errors: GContext, Value, Match, Alloc
Copies components from src-gc to dst-gc. The value-mask specifies
which components to copy, as for CreateGC. The two gcontexts must have
the same root and the same depth (else a Match error).
SetDashes
gc: GCONTEXT
dash-offset: CARD16
dash-list: LISTofCARD8
Errors: GContext, Value, Alloc
Sets the dash-offset and dash-list in gc for dashed line styles. The
initial and alternating elements of the dash-list are the "even"
dashes, the others are the "odd" dashes. All of the elements must be
non-zero. The dash-offset defines the phase of the pattern, specifying
how many pixels into the dash-list the pattern should actually begin in
any single graphics request. Dashing is continuous through path
segments combined with a join-style, but is reset to the dash-offset
each time a cap-style is applied.
SetClipRectangles
gc: GCONTEXT
clip-x-origin, clip-y-origin: INT16
rectangles: LISTofRECTANGLE
ordering: {UnSorted, YSorted, YXSorted, YXBanded}
Errors: GContext, Value, Alloc, Match
Changes clip-mask in gc to the specified list of rectangles and sets
the clip origin. Output will be clipped to remain contained within the
rectangles. The clip origin is interpreted relative to the origin of
whatever destination drawable is specified in a graphics request. The
rectangle coordinates are interpreted relative to the clip origin. The
rectangles should be non-intersecting, or graphics results will be
undefined.
If known by the client, ordering relations on the rectangles can be
specified with the ordering argument; this may provide faster operation
by the server. If an incorrect ordering is specified, the server may
generate a Match error, but is not required to do so; if no error is
generated, the graphics results are undefined. UnSorted means the
rectangles are in arbitrary order. YSorted means that the rectangles
are non-decreasing in their Y origin. YXSorted additionally constrains
YSorted order in that all rectangles with an equal Y origin are
non-decreasing in their X origin. YXBanded additionally constrains
YXSorted by requiring that for every possible Y scanline, all
rectangles that include that scanline have identical Y origins and Y
extents.
FreeGC
gc: GCONTEXT
Errors: GContext
Deletes the association between the resource id and the gcontext, and
destroys the gcontext.
ClearToBackground
window: WINDOW
x, y: INT16
width, height: CARD16
exposures: BOOL
Errors: Window, Value, Match
The x and y coordinates are relative to the window's origin, and
specify the upper left corner of the rectangle. If width is zero, it
is replaced with the current width of the window minus x. If height is
zero, it is replaced with the current height of the window minus y. If
the window has a defined background tile, the rectangle is tiled with a
plane-mask of all ones and alu-function of Copy. If the window has
background None, the contents of the window are not changed. In either
case, if exposures is True, then one or more exposure events are
generated for regions of the rectangle that are either visible or are
being retained in a backing store.
It is a Match error to use an InputOnly window in this request.
CopyArea
src-drawable, dst-drawable: DRAWABLE
gc: GCONTEXT
src-x, src-y: INT16
width, height: CARD16
dst-x, dst-y: INT16
Errors: Drawable, GContext, Match
Combines the specified rectangle of src-drawable with the specified
rectangle of dst-drawable. The src-x and src-y coordinates are
relative to src-drawable's origin, dst-x and dst-y are relative to
dst-drawable's origin, each pair specifying the upper left corner of
the rectangle. Src-drawable must have the same root and the same depth
as dst-drawable (else a Match error).
If regions of the source rectangle are obscured and have not been
retained by the server, or if regions outside the boundaries of the
source drawable are specified, then the following occurs. If the
dst-drawable is a window with a background of other than None, the
corresponding regions of the destination are tiled (with plane-mask of
all ones and alu-function Copy) with that background. Regardless, if
graphics-exposures in gc is True, GraphicsExposure events for the
corresponding destination regions are generated.
If graphics-exposures is True but no regions are exposed, then a
NoExposure event is generated.
GC components: alu-function, plane-mask, subwindow-mode,
graphics-exposures, clip-x-origin, clip-y-origin, clip-mask
CopyPlane
src-drawable, dst-drawable: DRAWABLE
gc: GCONTEXT
src-x, src-y: INT16
width, height: CARD16
dst-x, dst-y: INT16
bit-plane: CARD32
Errors: Drawable, GContext, Value, Match
Src-drawable must have the same root as dst-drawable (else a Match
error), but need not have the same depth. Bit-plane must have exactly
one bit set. Effectively, that plane of the src-drawable and the
foreground/background pixels in gc are combined to form a pixmap of the
same depth as dst-drawable, and the equivalent of a CopyArea is
performed, with all the same exposure semantics.
GC components: alu-function, plane-mask, foreground, background,
subwindow-mode, graphics-exposures, clip-x-origin, clip-y-origin,
clip-mask
PolyPoint
drawable: DRAWABLE
gc: GCONTEXT
coordinate-mode: {Origin, Previous}
points: LISTofPOINT
Errors: Drawable, GContext, Value, Match
Combines the foreground pixel in gc with the pixel at each point in the
drawable. The points are drawn in the order listed.
The first point is always relative to the drawable's origin; the rest
are relative either to that origin or the previous point, depending on
the coordinate-mode.
GC components: alu-function, plane-mask, foreground, subwindow-mode,
clip-x-origin, clip-y-origin, clip-mask
PolyLine
drawable: DRAWABLE
gc: GCONTEXT
coordinate-mode: {Origin, Previous}
points: LISTofPOINT
Errors: Drawable, GContext, Value, Match
Draws lines between each pair of points (point[i], point[i+1]). The
lines are drawn in the order listed. The lines join correctly at all
intermediate points, and if the first and last points coincide, the
first and last lines also join correctly.
For any given line, no pixel is drawn more than once. If thin (zero
line-width) lines intersect, the intersecting pixels are drawn multiple
times. If wide lines intersect, the intersecting pixels are drawn only
once, as though the entire PolyLine were a single filled shape.
The first point is always relative to the drawable's origin; the rest
are relative either to that origin or the previous point, depending on
the coordinate-mode.
GC components: alu-function, plane-mask, line-width, line-style,
cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
PolySegment
drawable: DRAWABLE
gc: GCONTEXT
segments: LISTofSEGMENT
where SEGMENT: [x1, y1, x2, y2: INT16]
Errors: Drawable, GContext, Match
For each segment, draws a line between [x1, y1] and [x2, y2]. The
lines are drawn in the order listed. No joining is performed at
coincident end points. For any given line, no pixel is drawn more than
once. If lines intersect, the intersecting pixels are drawn multiple
times.
GC components: alu-function, plane-mask, line-width, line-style,
cap-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin,
clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
PolyRectangle
drawable: DRAWABLE
gc: GCONTEXT
rectangles: LISTofRECTANGLE
Errors: Drawable, GContext, Match
Draws the outlines of the specified rectangles, as if a five-point
PolyLine were specified for each rectangle. The x and y coordinates of
each rectangle are relative to the drawable's origin, and define the
upper left corner of the rectangle.
The rectangles are drawn in the order listed. For any given rectangle,
no pixel is drawn more than once. If rectangles intersect, the
intersecting pixels are drawn multiple times.
GC components: alu-function, plane-mask, line-width, line-style,
join-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin,
clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 2 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:27:59 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:26-EDT
Date: Mon, 1 Jun 87 08:27 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 2 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082720.7.RWS@KILLINGTON.LCS.MIT.EDU>
SECTION 6. KEYBOARDS
Keycodes are always in the inclusive range [8,255].
For keyboards with both left-side and right-side modifier keys (e.g., Shift
and Control), the mask bits in the protocol always define the OR of the keys.
If electronically distinguishable, they can have separate up/down events
generated, and clients that want to distinguish can track the individual
states manually.
<As part of the core we need to define a universal association between keycaps
and keycodes. A keycap is the graphical information imprinted on a keyboard
key, e.g., "$ 4", "T", "+ =".>
SECTION 7. POINTERS
Buttons are always numbered starting with one.
SECTION 8. PREDEFINED ATOMS
Predefined atoms are not strictly necessary, and may not be useful in all
environments, but will eliminate many InternAtom requests in most
applications. The core protocol imposes no semantics on these names, except
as they are used in FONTPROP structures (see QueryFont). Note that
upper/lower case matters.
BITMAP ICON_SIZE RGB_GREEN_MAP
COMMAND ITALIC_ANGLE RGB_RED_MAP
COPYRIGHT MAX_SPACE SECONDARY
CUT_BUFFER0 MIN_SPACE SIZE_HINTS
CUT_BUFFER1 NAME STRIKEOUT_ASCENT
CUT_BUFFER2 NORMAL_HINTS STRIKEOUT_DESCENT
CUT_BUFFER3 NORM_SPACE STRING
CUT_BUFFER4 PIXMAP SUBSCRIPT_X
CUT_BUFFER5 POINT_SIZE SUBSCRIPT_Y
CUT_BUFFER6 PRIMARY SUPERSCRIPT_X
CUT_BUFFER7 QUAD_WIDTH SUPERSCRIPT_Y
DEFAULT_CHAR RECTANGLE UNDERLINE_POSITION
END_SPACE RESIZE_HINT UNDERLINE_THICKNESS
FACE_NAME RESOLUTION WEIGHT
FAMILY_NAME RGB_BEST_MAP WINDOW
FONT_ASCENT RGB_BLUE_MAP WM_HINTS
FONT_DESCENT RGB_COLOR_MAP X_HEIGHT
ICON RGB_DEFAULT_MAP ZOOM_HINTS
ICON_NAME
SECTION 9. CONNECTION SETUP
For remote clients, the X protocol can be built on top of any reliable byte
stream. For TCP connections, displays on a given host a numbered starting
from 0, and the server for display N listens and accepts connections on port
6000+N.
The client must send an initial byte of data to identify the byte order to be
employed. The value of the byte must be octal 102 or 154. The value 102
(ASCII uppercase B) means values are transmitted most significant byte first,
and value 154 (ASCII lowercase l) means values are transmitted least
significant byte first. Except where explicitly noted in the protocol, all
16-bit and 32-bit quantities sent by the client must be transmitted with this
byte order, and all 16-bit and 32-bit quantities returned by the server will
be transmitted with this byte order.
Following the byte-order byte, the following information is sent by the client
at connection setup:
protocol-major-version: CARD16
protocol-minor-version: CARD16
authorization-protocol-name: STRING8
authorization-protocol-data: STRING8
The version numbers indicate what version of the protocol the client
expects the server to implement. See below for an explanation.
The authorization name indicates what authorization protocol the client
expects the server to use, and the data is specific to that protocol.
Specification of valid authorization mechanisms is not part of the core
X protocol. It is hoped that eventually one authorization protocol
will be agreed upon. In the mean time, a server that implements a
different protocol than the client expects, or a server that only
implements the host-based mechanism, will simply ignore this
information.
Received by the client at connection setup:
success: BOOL
protocol-major-version: CARD16
protocol-minor-version: CARD16
length: CARD16
Length is the amount of additional data to follow, in units of 4 bytes.
The version numbers are an escape hatch in case future revisions of the
protocol are necessary. In general, the major version would increment
for incompatible changes, and the minor version would increment for
small upward compatible changes. Barring changes, the major version
will be eleven, and the minor version will be zero. The protocol
version numbers returned indicate the protocol the server actually
supports. This might not equal the version sent by the client. The
server can (but need not) refuse connections from clients that offer a
different version than the server supports. A server can (but need
not) support more than one version simultaneously.
Additional data received if authorization fails:
reason: STRING8
Additional data received if authorization is accepted:
vendor: STRING8
release-number: CARD32
resource-id-base, resource-id-mask: CARD32
image-byte-order: {LSBFirst, MSBFirst}
bitmap-format-scanline-unit: {8, 16, 32}
bitmap-format-scanline-pad: {8, 16, 32}
bitmap-format-bit-order: {LeastSignificant, MostSignificant}
pixmap-formats: LISTofFORMAT
roots: LISTofSCREEN
keyboard: DEVICE
pointer: DEVICE
motion-buffer-size: CARD32
maximum-request-length: CARD16
where
FORMAT: [depth: CARD8,
bits-per-pixel: {4, 8, 16, 24, 32}
scanline-pad: {8, 16, 32}]
SCREEN: [root: WINDOW
device: DEVICE
width-in-pixels, height-in-pixels: CARD16
width-in-millimeters, height-in-millimeters: CARD16
allowed-depths: LISTofDEPTH
root-depth: CARD8
root-visual: VISUALID
default-colormap: COLORMAP
white-pixel, black-pixel: CARD32
min-installed-maps, max-installed-maps: CARD16
backing-stores: {Never, WhenMapped, Always}
save-unders: BOOL
current-input-masks: SETofEVENT]
DEPTH: [depth: CARD8
visuals: LISTofVISUALTYPE]
VISUALTYPE: [visual-id: VISUALID
class: {StaticGray, StaticColor, TrueColor,
GrayScale, PseudoColor, DirectColor}
red-mask, green-mask, blue-mask: CARD32
bits-per-rgb-value: CARD8
colormap-entries: CARD16]
Per server information:
The vendor string gives some indentification of the owner of the server
implementation. The semantics of the release-number is controlled by
the vendor.
The resource-id-mask contains a single contiguous set of bits (at least
18); the client allocates resource ids by choosing a value with (only)
some subset of these bits set, and ORing it with resource-id-base.
Only values constructed in this way can be used to name newly created
resources over this connection. Resource ids never have the top 3 bits
set. The client is not restricted to linear or contiguous allocation
of resource ids. Once an id has been freed, it can be reused, but this
should not be necessary. An id must be unique with respect to the ids
of all other resources, not just other resources of the same type.
Although the server is in general responsible for byte swapping data to
match the client, images are always transmitted and received in formats
(including byte order) specified by the server. The byte order for
images is given by image-byte-order, and applies to each scanline unit
in XYFormat (bitmap) format, and to each pixel value in ZFormat.
A bitmap is represented in scanline order. Each scanline is padded to
a multiple of bits as given by bitmap-format-scanline-pad. The pad
bits are of arbitrary value. The scanline is quantized in multiples of
bits as given by bitmap-format-scanline-unit. Within each unit, the
leftmost bit in the bitmap is either the least or most significant bit
in the unit, as given by bitmap-format-bit-order. If a pixmap is
represented in XYFormat, each plane is represented as a bitmap, and the
planes appear from most to least significant in bit order.
For each pixmap depth supported by some screen, pixmap-formats lists
the ZFormat used to represent images of that depth. In ZFormat, the
pixels are in scanline order, left to right within a scanline. The
number of bits used to hold each pixel is given by bits-per-pixel, and
may be larger than strictly required by the depth. When the
bits-per-pixel is 4, the order of nibbles in the byte is the same as
the image byte-order. Each scanline is padded to a multiple of bits as
given by scanline-pad.
How a pointing device roams the screens is up to the server
implementation, and is transparent to the protocol. No geometry among
screens is defined.
The server may retain the recent history of pointer motion, and to a
finer granularity than is reported by MotionNotify events. Such
history is available via the GetPointerMotions request. The
approximate size of the history buffer is given by motion-buffer-size.
Maximum-request-length specifies the maximum length of a request, in
4-byte units, accepted by the server; i.e., this is the maximum value
that can appear in the length field of a request. Requests larger than
this generate a Length error, and the server will read and simply
discard the entire request. Maximum-request-length will always be at
least 4096 (i.e., requests of length up to and including 16384 bytes
will be accepted by all servers).
Per screen information:
The allowed-depths specifies what pixmap and window depths are
supported. Pixmaps are supported for each depth listed, and windows of
that depth are supported if at least one visual type is listed for the
depth. A pixmap depth of one is always supported and listed, but
windows of depth one might not be supported. A depth of zero is never
listed, but zero-depth InputOnly windows are always supported.
Root-depth and root-visual specify the depth and visual type of the
root window. Width-in-pixels and height-in-pixels specify the size of
the root window (which cannot be changed). The class of the root
window is always InputOutput. Width-in-millimeters and
height-in-millimeters can be used to determine the physical size and
the aspect ratio.
The default-colormap is the one initially associated with the root
window. Clients with minimal color requirements creating windows of
the same depth as the root may want to allocate from this map by
default.
Black-pixel and white-pixel can be used in implementing a "monochrome"
application. These pixel values are for permanently allocated entries
in the default-colormap; the actual RGB values may be settable on some
screens.
The border of the root window is initially a pixmap filled with the
black-pixel. The initial background of the root window is a pixmap
filled with some unspecified two-color pattern using black-pixel and
white-pixel.
Min-installed-maps specifies the number of maps that can be guaranteed
to installed simultaneously (with InstallColormap), regardless of the
number of entries allocated in each map. Max-installed-maps specifies
the maximum number of maps that might possibly be installed
simultaneously, depending on their allocations. For the typical case
of a single hardware colormap, both values will be one.
Backing-stores indicates when the server supports backing stores for
this screen, although it may be storage limited in the number of
windows it can support at once. If save-unders is True, then the
server can support the save-under mode in CreateWindow and
ChangeWindowAttributes, although again it may be storage limited.
The current-input-events is what GetWindowAttributes would return for
the all-event-masks for the root window.
Per visual-type information:
A given visual type might be listed for more than one depth, or for
more than one screen.
For PseudoColor, a pixel value indexes a colormap to produce
independent RGB values; the RGB values can be changed dynamically.
GrayScale is treated the same as PseudoColor, except which primary
drives the screen is undefined, so the client should always store the
same value for red, green, and blue in colormaps. For DirectColor, a
pixel value is decomposed into separate RGB subfields, and each
subfield separately indexes the colormap for the corresponding value;
The RGB values can be changed dynamically. TrueColor is treated the
same as DirectColor, except the colormap has predefined read-only RGB
values, which are server-dependent, but provide (near-)linear ramps in
each primary. StaticColor is treated the same as PseudoColor, except
the colormap has predefined read-only RGB values, which are
server-dependent. StaticGray is treated the same as StaticColor,
except the red, green, and blue values are equal for any single pixel
value, resulting in shades of gray. StaticGray with a two-entry
colormap can be thought of as "monochrome".
The red-mask, green-mask, and blue-mask are only defined for
DirectColor and TrueColor; each has one contiguous set of bits, with no
intersections.
The bits-per-rgb-value specifies the log base 2 of the approximate
number of distinct color values (individually) of red, green, and blue.
Actual RGB values are always passed in the protocol within a 16-bit
spectrum.
The colormap-entries defines the number of available colormap entries
in a newly created colormap. For DirectColor and TrueColor, this will
usually be the size of an individual pixel subfield.
SECTION 10. REQUESTS
CreateWindow
wid, parent: WINDOW
class: {InputOutput, InputOnly, CopyFromParent}
depth: CARD8
visual: VISUALID or CopyFromParent
x, y: INT16
width, height, border-width: CARD16
value-mask: BITMASK
value-list: LISTofVALUE
Errors: IDChoice, Window, Pixmap, Colormap, Cursor, Match, Value, Alloc
Creates an unmapped window, and assigns the identifier wid to it.
A class of CopyFromParent means the class is taken from the parent. A
depth of zero for class InputOutput or CopyFromParent means the depth
is taken from the parent. A visual of CopyFromParent means the visual
type is taken from the parent. For class InputOutput, the visual type
and depth must be a combination supported for the screen (else a Match
error); the depth need not be the same as the parent, but the parent
must not be of class InputOnly (else a Match error). For class
InputOnly, the depth must be zero (else a Match error), and the visual
must be one supported for the screen (else a Match error), but the
parent may have any depth and class.
The server essentially acts as if InputOnly windows do not exist for
the purposes of graphics requests, exposure processing, and
VisibilityNotify events. An InputOnly window cannot be used as a
drawable (as a source or destination for graphics requests). InputOnly
and InputOutput windows act identically in other respects (properties,
grabs, input control, and so on).
The window is placed on top in the stacking order with respect to
siblings. The x and y coordinates are relative to the parent's origin,
and specify the position of the upper left outer corner of the window
(not the origin). The width and height specify the inside size, not
including the border, and must be non-zero. The border-width for an
InputOnly window must be zero (else a Match error).
The value-mask and value-list specify attributes of the window that are
to be explicitly initialized. The possible values are:
background-pixmap: PIXMAP or None or ParentRelative
background-pixel: CARD32
border-pixmap: PIXMAP or CopyFromParent
border-pixel: CARD32
bit-gravity: BITGRAVITY
win-gravity: WINGRAVITY
backing-store: {NotUseful, WhenMapped, Always}
backing-bit-planes: CARD32
backing-pixel: CARD32
save-under: BOOL
event-mask: SETofEVENT
do-not-propagate-mask: SETofDEVICEEVENT
override-redirect: BOOL
colormap: COLORMAP or CopyFromParent
cursor: CURSOR or None
The default values, when attributes are not explicitly initialized,
are:
background-pixmap: None
border-pixmap: CopyFromParent
bit-gravity: Forget
win-gravity: NorthWest
backing-store: NotUseful
backing-bit-planes: all ones
backing-pixel: zero
save-under: False
event-mask: {} (empty set)
do-not-propagate-mask: {} (empty set)
override-redirect: False
colormap: CopyFromParent
cursor: None
Only the following attributes are defined for InputOnly windows:
win-gravity, event-mask, do-not-propagate-mask, and cursor. It is a
Match error to specify any other attributes for InputOnly windows.
If background-pixmap is given, it overrides the default
background-pixel. The background pixmap and the window must have the
same root and the same depth (else a Match error). Any size pixmap can
be used, although some sizes may be faster than others. If background
None is specifed, the window has no defined background. If background
ParentRelative is specified, the parent's background is used, but the
window must have the same depth as the parent (else a Match error); if
the parent has background None, then the window will also have
background None. A copy of the parent's background is not made; the
parent's background is reexamined each time the window background is
required. If background-pixel is given, it overrides the default and
any background-pixmap given, and a pixmap of undefined size filled with
background-pixel is used for the background. For a ParentRelative
background, the background tile origin always aligns with the parent's
background tile origin; otherwise the background tile origin is always
the window origin.
When regions of the window are exposed and the server has not retained
the contents, the server automatically tiles the regions with the
window's background unless the window has a background of None, in
which case the previous screen contents are simply left in place.
Exposure events are then generated for the regions, even if the
background is None.
The border tile origin is always the same as the background tile
origin. If border-pixmap is given, it overrides the default
border-pixel. The border pixmap and the window must have the same root
and the same depth (else a Match error). Any size pixmap can be used,
although some sizes may faster than others. If CopyFromParent is
given, the parent's border pixmap is copied (subsequent changes to the
parent do not affect the child), but the window must have the same
depth as the parent (else a Match error). If border-pixel is given, it
overrides the default and any border-pixmap given, and a pixmap of
undefined size filled with border-pixel is used for the border.
Output to a window is always clipped to the inside of the window, so
that the border is never affected.
The bit-gravity defines which region of the window should be retained
if the window is resized, and win-gravity defines how the window should
be repositioned if the parent is resized; see ConfigureWindow.
A backing-store of WhenMapped advises the server that maintaining
contents of obscured regions when the window is mapped would be
beneficial. A backing-store of Always advises the server that
maintaining contents even when the window is unmapped would be
beneficial. Note that, even if the window is larger than its parent,
the server should maintain complete contents, not just the region
within the parent boundaries. If the server maintains contents,
Exposure events will not be generated, but the server may stop
maintaining contents at any time. A value of NotUseful advises the
server that maintaining contents is unnecessary, although a server may
still choose to maintain contents.
Backing-bit-planes indicates (with one bits) which bit planes of the
window hold dynamic data that must be preserved in backing-stores.
Backing-pixel specifies what value to use in planes not covered by
backing-bit-planes. The server is free to only save the specified bit
planes in the backing-store, and regenerate the remaining planes with
the specified pixel value.
If save-under is True, the server is advised that, when this window is
mapped, saving the contents of windows it obscures would be beneficial.
The event-mask defines which events the client is interested in for
this window (or, for some event types, inferiors of the window). The
do-not-propagate-mask defines which events should not be propagated to
ancestor windows when no client has the event type selected in this
window.
Override-redirect specifies whether map and configure requests on this
window should override a SubstructureRedirect on the parent, typically
to inform a window manager not to tamper with the window.
The colormap specifies the colormap, that best reflects the "true"
colors of the window. Servers capable of supporting multiple hardware
colormaps may use this information, and window managers may use it for
InstallColormap requests. The colormap must have the same visual type
as the window (else a Match error). If CopyFromParent is specified,
the parent's colormap is copied (subsequent changes to the parent do
not affect the child), but the window must have the same visual type as
the parent (else a Match error) and the parent must not have a colormap
of None (else a Match error).
If a cursor is specified, it will be used whenever the pointer is in
the window. If None is specified, the parent's cursor will be used
when the pointer is in the window, and any change in the parent's
cursor will cause an immediate change in the displayed cursor.
This request generates a CreateNotify event.
The background and border pixmaps and the cursor may be freed
immediately if no further explicit references to them are to be made.
Subsequent drawing into the background or border pixmap has an
undefined effect on the window state; the server might or might not
make a copy of the pixmap.
ChangeWindowAttributes
window: WINDOW
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Window, Pixmap, Colormap, Cursor, Match, Value, Access
The value-mask and value-list specify which attributes are to be
changed. The values and restrictions are the same as for CreateWindow.
Changing the background does not cause the window contents to be
changed. Setting the border, or changing the background such that the
border tile origin changes, causes the border to be repainted.
Changing the background of a root window to None or ParentRelative
restores the default background pixmap. Changing the border of a root
window to CopyFromParent restores the default border pixmap.
Changing the win-gravity does not affect the current position of the
window.
Changing the backing-store of an obscured window to WhenMapped or
Always, or changing the backing-bit-planes, backing-pixel, or
save-under of a mapped window, may have no immediate effect.
Multiple clients can select input on the same window; their event-masks
are disjoint. When an event is generated it will be reported to all
interested clients. However, at most one client at a time can select
for SubstructureRedirect, at most one client at a time can select for
ResizeRedirect, and at most one client at a time can select for
ButtonPress.
There is only one do-not-propagate-mask for a window, not one per
client.
Changing the colormap of a window (i.e., defining a new map, not
changing the contents of the existing map) generates a ColormapNotify
event. Changing the colormap of a visible window may have no immediate
effect on the screen; see InstallColormap.
Changing the cursor of a root window to None restores the default
cursor.
The order in which attributes are verified and altered is server
dependent. If an error is generated, a subset of the attributes may
have been altered.
GetWindowAttributes
window: WINDOW
=>
visual: VISUALID
class: {InputOutput, InputOnly}
bit-gravity: BITGRAVITY
win-gravity: WINGRAVITY
backing-store: {NotUseful, WhenMapped, Always}
backing-bit-planes: CARD32
backing-pixel: CARD32
save-under: BOOL
colormap: COLORMAP or None
map-is-installed: BOOL
map-state: {Unmapped, Unviewable, Viewable}
all-event-masks, your-event-mask: SETofEVENT
do-not-propagate-mask: SETofDEVICEEVENT
override-redirect: BOOL
Errors: Window
Returns current attributes of the window. All-event-masks is the
inclusive-OR of all event masks selected on the window by clients.
Your-event-mask is the event mask selected by the querying client.
DestroyWindow
window: WINDOW
Errors: Window
If the argument window is mapped, an UnmapWindow request is performed
automatically. The window and all inferiors are then destroyed, and a
DestroyNotify event is generated for each window, in order from the
argument window downwards, with unspecified order among siblings at
each level.
Normal exposure processing on formerly obscured windows is performed.
If the window is a root window, this request has no effect.
DestroySubwindows
window: WINDOW
Errors: Window
Performs a DestroyWindow on all children of the window, in bottom to
top stacking order.
ChangeSaveSet
window: WINDOW
mode: {Insert, Delete}
Errors: Window, Match, Value
Adds or removes the specified window from the client's "save-set". The
window must have been created by some other client (else a Match
error). The use of the save-set is described in Section 11.
Windows are removed automatically from the save-set by the server when
they are destroyed.
ReparentWindow
window, parent: WINDOW
x, y: INT16
Errors: Window, Match
If the window is mapped, an UnmapWindow request is performed
automatically first. The window is then removed from its current
position in the hierarchy, and is inserted as a child of the specified
parent. The x and y coordinates are relative to the parent's origin,
and specify the new position of the upper left outer corner of the
window. The window is placed on top in the stacking order with respect
to siblings. A ReparentNotify event is then generated. The
override-redirect attribute of the window is passed on in this event; a
value of True indicates that a window manager should not tamper with
this window. Finally, if the window was originally mapped, a MapWindow
request is performed automatically.
Normal exposure processing on formerly obscured windows is performed.
The server might not generate exposure events for regions from the
initial unmap that are immediately obscured by the final map.
A Match error is generated if the new parent is not on the same screen
as the old parent, or if the new parent is the window itself or an
inferior of the window, or if the window has a ParentRelative
background and the new parent is not the same depth as the window.
MapWindow
window: WINDOW
Errors: Window
If the window is already mapped, this request has no effect.
If the override-redirect attribute of the window is False and some
other client has selected SubstructureRedirect on the parent, then a
MapRequest event is generated, but the window remains unmapped.
Otherwise, the window is mapped and a MapNotify event is generated.
If the window is now viewable and its contents had been discarded, then
the window is tiled with its background (if no background is defined,
the existing screen contents are not altered) and one or more exposure
events are generated. If a backing-store has been maintained while the
window was unmapped, no exposure events are generated. If a
backing-store will now be maintained, a full-window exposure is always
generated; otherwise only visible regions may be reported. Similar
tiling and exposure take place for any newly viewable inferiors.
MapSubwindows
window: WINDOW
Errors: Window
Performs a MapWindow request on all unmapped children of the window, in
top to bottom stacking order.
UnmapWindow
window: WINDOW
Errors: Window
If the window is already unmapped, this request has no effect.
Otherwise, the window is unmapped and an UnmapNotify event is
generated. Normal exposure processing on formerly obscured windows is
performed.
UnmapSubwindows
window: WINDOW
Errors: Window
Performs an UnmapWindow request on all mapped children of the window,
in bottom to top stacking order.
ConfigureWindow
window: WINDOW
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Window, Match, Value
Changes the configuration of the window. The value-mask and value-list
specify which values are to be given. The possible values are:
x: INT16
y: INT16
width: CARD16
height: CARD16
border-width: CARD16
sibling: WINDOW
stack-mode: {Above, Below, TopIf, BottomIf, Opposite}
The x and y coordinates are relative to the parent's origin, and
specify the position of the upper left outer corner of the window. The
width and height specify the inside size, not including the border, and
must be non-zero. It is a Match error to attempt to make the
border-width of an InputOnly window non-zero.
If the override-redirect attribute of the window is False and some
other client has selected SubstructureRedirect on the parent, then a
ConfigureRequest event is generated, and no further processing is
performed. Otherwise, the following is performed.
If some other client has selected ResizeRedirect on the window and the
width or height of the window is being changed, then a ResizeRequest
event is generated, and the current width and height are used instead
in the following.
The geometry of the window is changed as specified and the window is
restacked among siblings as described below, and a ConfigureNotify
event is generated. If the width or height of the window has actually
changed, then children of the window are affected as described below.
Exposure processing is performed on formerly obscured windows.
Changing the width or height of the window causes its contents to be
moved or lost, depending on the bit-gravity of the window, and causes
children to be reconfigured, depending on their win-gravity. For a
change of width and height of W and H, we define the [x, y] pairs:
NorthWest: [0, 0]
North: [W/2, 0]
NorthEast: [W, 0]
West: [0, H/2]
Center: [W/2, H/2]
East: [W, H/2]
SouthWest: [0, H]
South: [W/2, H]
SouthEast: [W, H]
When a window with one of these bit-gravities is resized, the
corresponding pair defines the change in position of each pixel in the
window. When a window with one of these win-gravities has its parent
window resized, the corresponding pair defines the change in position
of the window within the parent. When a window is so repositioned, a
GravityNotify event is generated.
A gravity of Static indicates that the contents or origin should not
move relative to the origin of the root window. If the change in size
of the window is coupled with a change in position of [X, Y], then for
bit-gravity the change in position of each pixel is [-X, -Y], and for
win-gravity the change in position of a child when its parent is so
resized is [-X, -Y]. Note that Static gravity still only takes effect
when the width or height of the window is changed, not when the window
is simply moved.
A bit-gravity of Forget indicates that the window contents are always
discarded after a size change; the window is tiled with its background
(if no background is defined, the existing screen contents are not
altered) and one or more exposure events are generated. A server may
also ignore the specified bit-gravity and use Forget instead.
A win-gravity of Unmap is like NorthWest, but the child is also
unmapped when the parent is resized, and an UnmapNotify event is
generated.
If a sibling and a stack-mode is specified, the window is restacked as
follows:
Above: window is placed just above sibling
Below: window is placed just below sibling
TopIf: if sibling occludes window, then window is placed
at the top of the stack
BottomIf: if window occludes sibling, then window is
placed at the bottom of the stack
Opposite: if sibling occludes window, then window is placed at the
top of the stack, else if window occludes sibling, then
window is placed at the bottom of the stack
If a stack-mode is specified but no sibling is specified, the window is
restacked as follows:
Above: window is placed at the top of the stack
Below: window is placed at the bottom of the stack
TopIf: if any sibling occludes window, then window is placed at
the top of the stack
BottomIf: if window occludes any sibling, then window is placed at
the bottom of the stack
Opposite: if any sibling occludes window, then window is placed at
the top of the stack, else if window occludes any
sibling, then window is placed at the bottom of the stack
It is a Match error if a sibling is specified without a stack-mode, or
if the window is not actually a sibling.
Note that the computations for BottomIf, TopIf, and Opposite are
performed with respect to the window's final geometry (as controlled by
the other arguments to the request), not its initial geometry.
CirculateWindow
window: WINDOW
direction: {RaiseLowest, LowerHighest}
Errors: Window, Value
If some other client has selected SubstructureRedirect on the window,
then a CirculateRequest event is generated, and no further processing
is performed. Otherwise, the following is performed, and then a
CirculateNotify event is generated if the window is actually restacked.
For RaiseLowest, raises the lowest mapped child (if any) that is
occluded by another child to the top of the stack. For LowerHighest,
lowers the highest mapped child (if any) that occludes another child to
the bottom of the stack. Exposure processing is performed on formerly
obscured windows.
∂01-Jun-87 0531 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 6 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:31:02 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:28-EDT
Date: Mon, 1 Jun 87 08:29 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 6 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082914.1.RWS@KILLINGTON.LCS.MIT.EDU>
SetPointerMapping
map: LISTofCARD8
=>
status: {Success, Busy}
Errors: Value
Sets the mapping of the pointer. Elements of the list are indexed
starting from one. The length of the list must be the same as
GetPointerMapping would return. The index is a "core" button number,
and the element of the list defines the "effective" number.
A zero element disables a button, and elements are not restricted in
value by the number of physical buttons, but no two elements can have
the same non-zero value.
If any of the buttons to be altered are currently in the down state,
the status reply is Busy and the mapping is not changed.
GetPointerMapping
=>
map: LISTofCARD8
Errors: Value
Returns the current mapping of the pointer. Elements of the list are
indexed starting from one. The length of the list indicates the number
of physical buttons.
The nominal mapping for a pointer is the identity mapping; map[i]=i.
ChangePointerControl
do-acceleration, do-threshold: BOOL
acceleration-numerator, acceleration-denominator: INT16
threshold: INT16
Errors: Match, Value
Defines how the pointer moves. The acceleration is a multiplier for
movement, expressed as a fraction. For example, specifying 3/1 means
the pointer moves three times as fast as normal. The fraction may be
rounded arbitrarily by the server. Acceleration only takes effect if
the pointer moves more than threshold pixels at once, and only applies
to the amount beyond the threshold. Setting a value to -1 restores the
default. Other negative values generate a Value error, as does a zero
value for acceleration-denominator.
GetPointerControl
=>
acceleration-numerator, acceleration-denominator: CARD16
threshold: CARD16
Errors: Match
Returns the current acceleration and threshold for the pointer.
SetScreenSaver
timeout, interval: INT16
prefer-blanking: {Yes, No, Default}
allow-exposures: {Yes, No, Default}
Errors: Value
Timeout and interval are specified in minutes; setting a value to -1
restores the default. Other negative values generate a Value error.
If the timeout value is zero, screen-saver is disabled. If the timeout
value is non-zero, screen-saver is enabled. Once screen-saver is
enabled, if no input from the keyboard or pointer is generated for
timeout minutes, screen-saver is activated. For each screen, if
blanking is preferred and the hardware supports video blanking, the
screen will simply go blank. Otherwise, if either exposures are
allowed or the screen can be regenerated without sending exposure
events to clients, the screen is tiled with the root window background
tile, randomly re-origined each interval minutes if the interval value
is non-zero. Otherwise, the state of the screen does not change and
screen-saver is not activated. Screen-saver is deactivated, and all
screen states are restored, at the next keyboard or pointer input or at
the next ForceScreenSaver with mode Reset.
GetScreenSaver
=>
timeout, interval: CARD16
prefer-blanking: {Yes, No}
allow-exposures: {Yes, No}
Returns the current screen-saver control values.
ForceScreenSaver
mode: {Activate, Reset}
If the mode is Activate and screen-saver is currently deactivated, then
screen-saver is activated (even if screen-saver has been disabled with
a timeout value of zero). If the mode is Reset and screen-saver is
currently enabled, then screen-saver is deactivated (if it was
activated), and then the activation timer is reset to its initial
state, as if device input had just been received.
ChangeHosts
mode: {Insert, Delete}
host: HOST
Errors: Access, Value
Adds or removes the specified host from the access control list. When
the access control mechanism is enabled and a host attempts to
establish a connection to the server, the host must be in this list or
the server will refuse the connection.
The client must reside on the same host as the server, and/or have been
granted permission in the initial authorization at connection setup.
An initial access control list can be specified, typically by naming a
file that the server reads at startup and reset.
ListHosts
=>
mode: {Enabled, Disabled}
hosts: LISTofHOST
Returns the hosts on the access control list, and whether use of the
list at connection setup is currently enabled or disabled.
Each HOST is padded to a multiple of four bytes.
ChangeAccessControl
mode: {Enable, Disable}
Errors: Value, Access
Enables or disables the use of the access control list at connection
setups.
The client must reside on the same host as the server, and/or have been
granted permission in the initial authorization at connection setup.
ChangeCloseDownMode
mode: {Destroy, RetainPermanent, RetainTemporary}
Errors: Value
Defines what will happen to the client's resources at connection close.
A connection starts in Destroy mode. The meaning of the close-down
mode is described in Section 11.
KillClient
resource: CARD32 or AllTemporary
Errors: Value
If a valid resource is specified, forces a close-down of the client
that created the resource. If the client has already terminated in
either RetainPermanent or RetainTemporary mode, all of the client's
resources are destroyed (see Section 11). If AllTemporary is
specified, then the resources of all clients that have terminated in
RetainTemporary are destroyed.
NoOperation
This request has no arguments and no results, but the request length
field can be non-zero, allowing the request to be any multiple of 4
bytes in length. The bytes contained in the request are uninterpreted
by the server.
This request can be used in its minimum 4 byte form as "padding" where
necessary by client libraries that find it convenient to force requests
to begin on 64-bit boundaries.
SECTION 11. CONNECTION CLOSE
What happens at connection close:
All event selections made by the client are discarded. If the client
has the pointer actively grabbed, an UngrabPointer is performed. If
the client has the keyboard actively grabbed, an UngrabKeyboard is
performed. All passive grabs by the client are released. If the
client has the server grabbed, and UngrabServer is performed. If
close-down mode (see ChangeCloseDownMode) is RetainPermanent or
RetainTemporary, then all resources (including colormap entries)
allocated by the client are marked as "permanent" or "temporary",
respectively (but this does not prevent other clients from explicitly
destroying them). If the mode is Destroy, then all of the client's
resources are destroyed as described below.
What happens when a client's resources are destroyed:
For each window in the client's save-set, if the window is an inferior
of a window created by the client, the save-set window is reparented to
the closest ancestor such that the save-set window is not an inferior
of a window created by the client. If the save-set window is unmapped,
a MapWindow request is performed on it. After save-set processing, all
windows created by the client are destroyed. For each non-window
resource created by the client, the appropriate Free request is
performed. All colors and colormap entries allocated by the client are
freed.
What happens when the last connection to a server closes:
A server goes through a cycle, of having no connections and having some
connections. At every transition to the state of having no
connections, the server "resets" its state, as if it had just been
started. This starts by destroying all lingering resources from
clients that have terminated in RetainPermanent or RetainTemporary
mode. It additionally includes deleting all but the predefined atom
identifiers, deleting all properties on all root windows, resetting all
device maps and attributes (key click, bell volume, acceleration),
resetting the access control list, restoring the standard root tiles
and cursors, restoring the default font path, and restoring the input
focus to state PointerRoot.
SECTION 12. EVENTS
When a button is pressed with the pointer in some window W, and no active
pointer grab is in progress, then the ancestors of W are searched from the
root down, looking for a passive grab to activate. If no matching passive
grab on the button exists, then an active grab is started automatically for
the client receiving the event, and the last-pointer-grab time is set to the
current server time. The effect is essentially equivalent to a GrabButton
with arguments:
event-window: the event window
event-mask: the client's selected events on the event window
pointer-mode and keyboard-mode: Asynchronous
owner-events: True if the client has OwnerGrabButton selected on the
event window, else False
confine-to: None
cursor: None
The grab is terminated automatically when all buttons are released.
UngrabPointer and ChangeActiveGrab can both be used to modify the active grab.
KeyPress
and
KeyRelease
and
ButtonPress
and
ButtonRelease
and
MotionNotify
root, event: WINDOW
child: WINDOW or None
same-screen: BOOL
root-x, root-y, event-x, event-y: INT16
detail: <see below>
state: SETofKEYBUTMASK
time: TIMESTAMP
Generated when a key or button changes state, or the pointer moves.
The "source" of the event is the window the pointer is in. The window
with respect to which the event is normally reported is found by
looking up the hierarchy (starting with the source window) for the
first window on which any client has selected interest in the event,
provided no intervening window prohibits event generation by including
the event type in its do-not-propagate-mask. The actual window used
for reporting can be modified by active grabs and the focus window.
The window the event is reported with respect to is called the "event"
window.
Root is the root window of the "source" window, and root-x and root-y
are the pointer coordinates relative to root's origin at the time of
the event. Event is the "event" window. If the event window is on the
same screen as root, then event-x and event-y are the pointer
coordinates relative to the event window's origin; otherwise event-x
and event-y are zero. If the source window is an inferior of the event
window, then child is set to the child of the event window that is an
ancestor of the source window. The state component gives the state of
the buttons and modifier keys just before the event. The detail
component varies with the event type:
KeyPress, KeyRelease: KEYCODE
ButtonPress, ButtonRelease: BUTTON
MotionNotify: {Normal, Hint}
MotionNotify events are only generated when the motion begins and ends
in the window. The granularity of motion events is not guaranteed, but
a client selecting for motion events is guaranteed to get at least one
event when the pointer moves and comes to rest. Selecting
PointerMotion receives events independent of the state of the pointer
buttons. By selecting some subset of Button[1-5]Motion instead,
MotionNotify events will only be received when one or more of the
specified buttons are pressed. By selecting ButtonMotion, MotionNotify
events will received only when at least one button is pressed. The
events are always of type MotionNotify, independent of the selection.
If PointerMotionHint is selected, the server is free to send only one
MotionNotify event (with detail Hint) to the client for the event
window, until either the key or button state changes, or the pointer
leaves the event window, or the client issues a QueryPointer or
GetMotionEvents request.
EnterNotify
and
LeaveNotify
root, event: WINDOW
child: WINDOW or None
same-screen: BOOL
root-x, root-y, event-x, event-y: INT16
mode: {Normal, Grab, Ungrab}
detail: {Ancestor, Virtual, Inferior, Nonlinear, NonlinearVirtual}
focus: BOOL
state: SETofKEYBUTMASK
time: TIMESTAMP
If pointer motion causes the pointer to be in a different window than
before, EnterNotify and LeaveNotify events are generated instead of a
MotionNotify event. Only clients selecting EnterWindow on a window
receive EnterNotify events, and only clients selection LeaveNotify
receive LeaveNotify events. The pointer position reported in the event
is always the "final" position, not the "initial" position of the
pointer. In a LeaveNotify event, if a child of the event window
contains the "initial" position of the pointer, then the child
component is set to that child, otherwise it is None. For an
EnterNotify event, if a child of the event window contains the "final"
pointer position, then the child component is set to that child,
otherwise it is None. If the the event window is the focus window or
an inferior of the focus window, then focus is True, and otherwise
focus is False.
Normal pointer motion events have mode Normal; pseudo-motion events
when a grab actives have mode Grab, and pseudo-motion events when a
grab deactivates have mode Ungrab.
Normal events are generated as follows:
When the pointer moves from window A to window B, and A is an inferior
of B:
LeaveNotify with detail Ancestor is generated on A
LeaveNotify with detail Virtual is generated on each window between
A and B exclusive (in that order)
EnterNotify with detail Inferior is generated on B
When the pointer moves from window A to window B, and B is an inferior
of A:
LeaveNotify with detail Inferior is generated on A
EnterNotify with detail Virtual is generated on each window between
A and B exclusive (in that order)
EnterNotify with detail Ancestor is generated on B
When the pointer moves from window A to window B, with window C being
their least common ancestor:
LeaveNotify with detail Nonlinear is generated on A
LeaveNotify with detail NonlinearVirtual is generated on each window
between A and C exclusive (in that order)
EnterNotify with detail NonlinearVirtual is generated on each window
between C and B exclusive (in that order)
EnterNotify with detail Nonlinear is generated on B
When the pointer moves from window A to window B, on different screens:
LeaveNotify with detail Nonlinear is generated on A
LeaveNotify with detail NonlinearVirtual is generated on each window
above A up to and including its root (in order)
EnterNotify with detail NonlinearVirtual is generated on each window
from B's root down to but not including B (in order)
EnterNotify with detail Nonlinear is generated on B
When a pointer grab activates (but after any initial warp into a confine-to
window), with G the grab-window for the grab and P the window the pointer
is in:
EnterNotify and LeaveNotify events with mode Grab are generated (as for
Normal above) as if the pointer were to suddenly warp from its current
position in P to some position in G. However, the pointer does not
warp, and the pointer position is used as both the "initial" and
"final" positions for the events.
When a pointer grab deactivates, with G the grab-window for the grab and P
the window the pointer is in:
EnterNotify and LeaveNotify events with mode Ungrab are generated (as
for Normal above) as if the pointer were to suddenly warp from from
some position in G to its current position in P. However, the pointer
does not warp, and the current pointer position is used as both the
"initial" and "final" positions for the events.
FocusIn
and
FocusOut
event: WINDOW
mode: {Normal, WhileGrabbed, Grab, Ungrab}
detail: {Ancestor, Virtual, Inferior, Nonlinear, NonlinearVirtual,
Pointer, PointerRoot, None}
Generated when the input focus changes. Reported to clients selecting
FocusChange on the window. Events generated by SetInputFocus when the
keyboard is not grabbed have mode Normal; events generated by
SetInputFocus when the keyboard is grabbed have mode WhileGrabbed;
events generated when a keyboard grab actives have mode Grab, and
events generated when a keyboard grab deactivates have mode Ungrab.
Normal and WhileGrabbed events are generated as follows:
When the focus moves from window A to window B, and A is an inferior of B,
with the pointer in window P:
FocusOut with detail Ancestor is generated on A
FocusOut with detail Virtual is generated on each window between
A and B exclusive (in that order)
FocusIn with detail Inferior is generated on B
If P is an inferior of B, but P is not A or an inferior of A or an
ancestor of A, FocusIn with detail Pointer is generated on
each window below B down to and including P (in order)
When the focus moves from window A to window B, and B is an inferior of A,
with the pointer in window P:
If P is an inferior of A, but P is not A or an inferior of B or an
ancestor of B, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Inferior is generated on A
FocusIn with detail Virtual is generated on each window between
A and B exclusive (in that order)
FocusIn with detail Ancestor is generated on B
When the focus moves from window A to window B, with window C being their
least common ancestor, and with the pointer in window P:
If P is an inferior of A, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Nonlinear is generated on A
FocusOut with detail NonlinearVirtual is generated on each window
between A and C exclusive (in that order)
FocusIn with detail NonlinearVirtual is generated on each window
between C and B exclusive (in that order)
FocusIn with detail Nonlinear is generated on B
If P is an inferior of B, FocusIn with detail Pointer is generated on
each window below B down to and including P (in order)
When the focus moves from window A to window B, on different screens, with
the pointer in window P:
If P is an inferior of A, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Nonlinear is generated on A
FocusOut with detail NonlinearVirtual is generated on each window
above A up to and including its root (in order)
FocusIn with detail NonlinearVirtual is generated on each window
from B's root down to but not including B (in order)
FocusIn with detail Nonlinear is generated on B
If P is an inferior of B, FocusIn with detail Pointer is generated on
each window below B down to and including P (in order)
When the focus moves from window A to PointerRoot (or None)
If P is an inferior of A, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Nonlinear is generated on A
FocusOut with detail NonlinearVirtual is generated on each window
above A up to and including its root (in order)
FocusIn with detail PointerRoot (or None) is generated on all root
windows
When the focus moves from PointerRoot (or None) to window A:
FocusOut with detail PointerRoot (or None) is generated on all root
windows
FocusIn with detail NonlinearVirtual is generated on each window from
A's root down to but not including A (in order)
FocusIn with detail Nonlinear is generated on A
If P is an inferior of A, FocusIn with detail Pointer is generated on
each window below A down to and including P (in order)
When the focus moves from PointerRoot to None (or vice versa):
FocusOut with detail PointerRoot (or None) is generated on all root
windows
FocusIn with detail None (or PointerRoot) is generated on all root
windows
When a keyboard grab activates, with G the grab-window for the grab and F
the current focus:
FocusIn and FocusOut events with mode Grab are generated (as for Normal
above) as if the focus were to change from F to G
When a keyboard grab deactivates, with G the grab-window for the grab and F
the current focus:
FocusIn and FocusOut events with mode Ungrab are generated (as for
Normal above) as if the focus were to change from G to F
KeymapNotify
keys: LISTofCARD8
The value is a bit vector, as described in QueryKeymap. Reported to
clients selecting KeymapState on a window. Generated immediately after
every EnterNotify and FocusIn.
Expose
window: WINDOW
x, y, width, height: CARD16
last-in-series: BOOL
Reported to clients selecting Exposure on the window. Possibly
generated when a region of the window becomes viewable, but might only
be generated when a region becomes visible. All of the regions exposed
by a given "action" are guaranteed to be reported contiguously; if
last-in-series is False then another exposure follows.
The x and y coordinates are relative to drawable's origin, and specify
the upper left corner of a rectangule. The width and height specify
the extent of the rectangle.
Expose events are never generated on InputOnly windows.
GraphicsExposure
drawable: DRAWABLE
x, y, width, height: CARD16
last-in-series: BOOL
major-opcode: CARD8
minor-opcode: CARD16
Reported to clients selecting graphics-exposures in a graphics context.
Generated when a destination region could not be computed due to an
obscured or out-of-bounds source region. All of the regions exposed by
a given graphics request are guaranteed to be reported contiguously; if
last-in-series is False then another exposure follows.
The x and y coordinates are relative to drawable's origin, and specify
the upper left corner of a rectangule. The width and height specify
the extent of the rectangle.
The major and minor opcodes identify the graphics request used. For
the core protocol, major-opcode is always CopyArea or CopyPlane and
minor-opcode is always zero.
NoExposure
drawable: DRAWABLE
major-opcode: CARD8
minor-opcode: CARD16
Reported to clients selecting graphics-exposures in a graphics context.
Generated when a graphics request that might produce GraphicsExposure
events does not produce any. The drawable specifies the destination
used for the graphics request.
The major and minor opcodes identify the graphics request used. For
the core protocol, major-opcode is always CopyArea or CopyPlane and
minor-opcode is always zero.
VisibilityNotify
window: WINDOW
state: {Unobscured, PartiallyObscured, FullyObscured}
Reported to clients selecting VisibilityChange on the window. In the
following, the state of the window is calculated ignoring all of the
window's subwindows. When a window changes state from partially or
fully obscured or not viewable to viewable and completely unobscured,
an event with Unobscured is generated. When a window changes state
from a) viewable and completely unobscured or b) not viewable, to
viewable and partially obscured, an event with PartiallyObscured is
generated. When a window changes state from a) viewable and completely
unobscured or b) viewable and partially obscured or c) not viewable, to
viewable and fully obscured, an event with FullyObscured is generated.
VisibilityNotify events are never generated on InputOnly windows.
CreateNotify
parent, window: WINDOW
x, y: INT16
width, height, border-width: CARD16
override-redirect: BOOL
Reported to clients selecting SubstructureNotify on the parent.
Generated when the window is created. The arguments are as in the
CreateWindow request.
DestroyNotify
event, window: WINDOW
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window is destroyed. "Event" is the window on which the event was
generated, and "window" is the window that is destroyed.
UnmapNotify
event, window: WINDOW
from-configure: BOOL
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window changes state from mapped to unmapped. "Event" is the window on
which the event was generated, and "window" is the window that is
unmapped. The from-configure flag is True if the event was generated
as a result of the window's parent being resized when the window itself
had a win-gravity of Unmap.
MapNotify
event, window: WINDOW
override-redirect: BOOL
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window changes state from unmapped to mapped. "Event" is the window on
which the event was generated, and "window" is the window that is
mapped. The override-redirect flag is from the window's attribute.
MapRequest
parent, window: WINDOW
Reported to the client selecting SubstructureRedirect on the parent.
Generated when a MapWindow request is issued on an unmapped window with
an override-redirect attribute of False.
ReparentNotify
event, window, parent: WINDOW
x, y: INT16
override-redirect: BOOL
Reported to clients selecting SubstructureNotify on either the old or
the new parent, and to clients selecting StructureNotify on the window.
Generated when the window is reparented. "Event" is the window on
which the event was generated, "window" is the window that has been
re-rooted, and "parent" specifies the new parent. The x and y
coordinates are relative to the new parent's origin, and specify the
position of the upper left outer corner of the window. The
override-redirect flag is from the window's attribute.
ConfigureNotify
event, window: WINDOW
x, y: INT16
width, height, border-width: CARD16
above-sibling: WINDOW or None
override-redirect: BOOL
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when a
ConfigureWindow request actually changes the state of the window.
"Event" is the window on which the event was generated, and "window" is
the window that is changed. If above-sibling is None, then the window
is on the bottom of the stack with respect to siblings; otherwise, the
window is immediately on top of the specified sibling. The
override-redirect flag is from the window's attribute.
GravityNotify
event, window: WINDOW
x, y: INT16
Reported to clients selecting SubstructureNotify on the parent, and to
clients selecting StructureNotify on the window. Generated when a
window is moved because of a change in size of the parent. "Event" is
the window on which the event was generated, and "window" is the window
that is moved.
ResizeRequest
window: WINDOW
width, height: CARD16
Reported to the client selecting ResizeRedirect on the window.
Generated when a ConfigureWindow request by some other client on the
window attempts to change the size of the window. The width and height
are the inside size, not including the border.
ConfigureRequest
parent, window: WINDOW
x, y: INT16
width, height, border-width: CARD16
above-sibling: WINDOW or None
Reported to the client selecting SubstructureRedirect on the parent.
Generated when a ConfigureWindow request is issued on the window by
some other client. The geometry is as derived from the request. The
above-sibling is the sibling the window should be placed directly on
top of; if None, then the window should be placed on the bottom.
CirculateNotify
event, window: WINDOW
place: {Top, Bottom}
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window is actually restacked from a CirculateWindow request. "Event"
is the window on which the event was generated, and "window" is the
window that is restacked. If place is Top, the window is now on top of
all siblings; otherwise it is below all siblings.
CirculateRequest
parent, window: WINDOW
place: {Top, Bottom}
Reported to the client selecting SubstructureRedirect on the parent.
Generated when a CirculateWindow request is issued on the parent and a
window actually needs to be restacked. The window specifies the window
to be restacked, and place specifies what the new position in the
stacking order should be.
PropertyNotify
window: WINDOW
atom: ATOM
state: {NewValue, Deleted}
time: TIMESTAMP
Reported to clients selecting PropertyChange on the window. Generated
when a property of the window is changed. The timestamp indicates the
server time when the property was changed.
SelectionClear
owner: WINDOW
selection: ATOM
time: TIMESTAMP
Reported to the current owner of a selection. Generated on the window
losing ownership when a new owner is being defined. The timestamp is
the last-change time recorded for the selection.
SelectionRequest
owner: WINDOW
selection: ATOM
target: ATOM
property: ATOM or None
requestor: WINDOW
time: TIMESTAMP or CurrentTime
Reported to the owner of a selection. Generated when a client issues a
ConvertSelection request. The arguments are as in the request.
The owner should convert the selection based on the specified target
type. If a property is specified, the owner should store the result as
that property on the requestor window, and then send a SelectionNotify
event to the requestor using SendEvent. If the selection cannot be
converted as requested, the owner should send a SelectionNotify with
the property set to None.
SelectionNotify
requestor: WINDOW
selection, target: ATOM
property: ATOM or None
time: TIMESTAMP or CurrentTime
This event is only generated by clients using SendEvent. The owner of
a selection should send this event to a requestor when a selection has
been converted and stored as a property, or when a selection conversion
could not be performed (indicated with property None).
ColormapNotify
window: WINDOW
colormap: COLORMAP or None
new: BOOL
state: {Installed, Uninstalled}
Reported to clients selecting ColormapChange on the window. Generated
with value True for new when the colormap attribute of the window is
changed. Generated with value False for new when the colormap of a
window is installed or uninstalled. In either case, state indicates
whether the colormap is currently installed.
ClientMessage
window: WINDOW
type: ATOM
format: {8, 16, 32}
data: LISTofINT8 or LISTofINT16 or LISTofINT32
This event is only generated by clients using SendEvent. The type
specifies how the data is to be interpreted by the receiving client;
the server places no interpretation on the type or the data. The
format specifies whether the data should be viewed as a list of 8-bit,
16-bit, or 32-bit quantities, so that the server can correctly
byte-swap as necessary. The data always consists of either 20 8-bit
values or 10 16-bit values or 5 32-bit values, although particular
message types might not make use of all of these values.
SECTION 12. FLOW CONTROL AND CONCURRENCY
Whenever the server is writing to a given connection, it is permissible for
the server to stop reading from that connection (but if the writing would
block it must continue to service other connections). The server is not
required to buffer more than a single request per connection at one time. For
a given connection to the server, a client can block while reading from the
connection, but should undertake to read (events and errors) when writing
would block. Failure on the part of a client to obey this rule could result
in a deadlocked connection, although deadlock is probably unlikely unless the
transport layer has very little buffering, or unless the client attempts to
send large numbers of requests without ever reading replies or checking for
errors and events.
If a server is implemented with internal concurrency, the overall effect must
be as if individual requests are executed to completion in some serial order,
and that requests from a given connection are executed in delivery order
(i.e., the total execution order is a shuffle of the individual streams). The
"execution" of a request includes validating all arguments, collecting all
data for any reply, and generating (and queueing) all required events, but
does not include the actual transmission of the reply and the events. In
addition, the effect of any other "cause" (e.g., activation of a grab, pointer
motion) that can generate multiple events must effectively generate (and
queue) all required events indivisibly with respect to all other causes and
requests.
∂11-Jun-87 1121 Masinter.pa@Xerox.COM Issues from the cleanup committee
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 11:20:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 11:15:28 PDT
Date: 11 Jun 87 11:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Issues from the cleanup committee
To: X3J13@Sail.stanford.edu
Message-ID: <870611-111528-1358@Xerox>
The cleanup committee has been hard at work. We have produced a number
of issues for presentation at the next meeting. I will mail drafts of
the issues which seem ready to release to this list over the next
several days. I will then mail out a summary. A hardcopy of the issues
will also be mailed to the X3J13 mailing list.
Discussion is still on-going in cl-cleanup. There are a few proposals
that are in the last rounds of revisions which we will try finalize in
the next few days.
∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue DEFVAR-INIT-TIME (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:20:55 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:34:46 PDT
Date: 11 Jun 87 13:33 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue DEFVAR-INIT-TIME (Version 2)
To: x3j13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <870611-133446-1639@Xerox>
!
Issue: DEFVAR-INIT-TIME
References: DEFVAR (p68)
Category: CLARIFICATION
Edit history: 23-Apr-87, Version 1 by Pitman
29-Mar-87, Version 2 by Masinter
Problem Description:
The description of DEFVAR is not completely clear about the time at
which the initialization occurs.
On p68 it says ``VARIABLE is initialized to the result of evaluating the
form INITIAL-VALUE unless it already has a value. The INITIAL-VALUE form
is not evaluated unless it is used; this fact is useful if evaluation of
the INITIAL-VALUE form does something expensive like create a large data
structure.''
At least one implementation interpreted the "unless it is used" to mean
"unless the variable is used" rather than "unless the initial-value is
to be used". The problem is that the "it" is ambiguous. Thus, DEFVAR was
interpreted as a kind of lazy initialization that happened upon the
variable's first unbound reference. (This interpretation appears to have
been further supported by the additional wording in CLtL about not
creating expensive structures that are not needed.)
Proposal (DEFVAR-INIT-TIME:NOT-DELAYED):
Clarify that the evaluation of the initial value and the initialization
happen at DEFVAR execution time (if at all). The cause of the confusion
is the statement that the initial value form is not evaluated unless "it
is used". Better to say that INITIAL-VALUE is evaluated if and only if
the variable does not already have a value. Then there would be no
confusion about the time of evaluation.
Rationale:
This clarification follows the intent of the original Common Lisp
designers.
Current Practice:
Nearly all implementations implement the proposed interpretation.
Adoption Cost:
None, for most implementations; very small for any the implementation
that adopted delayed evaluation.
Benefits:
This clarification makes the semantics of an important primitive more
well-defined.
Conversion Cost:
Most users presumably expect the behavior currently in practice in most
dialects. There's not a lot of code where the difference comes into play
anyway. Presumably the conversion cost is fairly trivial.
Aesthetics:
Being a clarification, this really doesn't have much aesthetic effect.
Discussion:
The cleanup committee supports this clarification.
∂11-Jun-87 1619 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 11)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:19:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:03:36 PDT
Date: 11 Jun 87 13:03 PDT
From: Masinter.pa@Xerox.COM
Subject: Format for proposals to the cleanup committee (Version 11)
To: X3J13@Sail.stanford.edu
Line-fold: no
Message-ID: <870611-130336-1594@Xerox>
!
Format for proposals to the cleanup committee (Version 11)
June 11, 1987
Replace the text below in >> double inverted angle-brackets <<. Be brief; leave testimonials and personal opinions to the discussion at the end. Be complete; do not expect someone else to fix or redesign parts. Spell out names (e.g., Masinter rather than LMM) and upcase all Lisp symbols (DEFUN rather than Defun). I like it better if you write in the third person rather than first.
Issue: >>A short descriptive label, which starts with a name which occurs in the index of CLtL, and be a suitable symbol in the Common Lisp style, e.g., CDR-TERMINATION.<<
References: >>The pages of CLtL which describe the feature being discussed, or other references.<<
Category: >>One or more of: CLARIFICATION -- proposal to resolve an ambiguity or case of under-specified situation in CLtL, where this ambiguity interferes with portability of code. CHANGE -- proposal for an incompatible change to the language. ADDITION -- proposal for a compatible extension to the language. <<
Edit history: >>Author and date of submission (version 1), and author and date of subsequent versions.<<
Problem description:
>>Describe the problem being addressed -- why is the current situation unclear or unsatisfactory? Avoid describing the proposal here or arguing for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as possible what you are proposing. Ideally, this should take the form of text that could be dropped into CLtL or some new specification document. If necessary, propose a set of labelled alternatives here, rather than a single proposal. Each proposal must be a complete design; do not leave out details. Avoid arguing for the proposal here, just describe it.<<
Test Case:
>>When possible, give a sample of Common Lisp code that illustrates the issue. The code should stand alone, and preferably be suitable for incorporation in a diagnostic suite. <<
Rationale:
>> A brief argument for the proposal. (If more than one proposal is listed, discuss each issue separately here and in subsequent sections.)<<
Current practice:
>>Do some/many/no Common Lisp implementations already work this way? Survey independent Common Lisp implementations - preferably three or more.<<
Adoption Cost:
>>What is the cost to implementors of adopting the proposal? How much implementation effort is required? Is public-domain code available? For pervasive changes, can the conversion be automated?<<
Cost of non-adoption:
>>How serious is it if nothing is done? <<
Benefits:
>>What is better if the proposal is adopted? How serious is the problem if just left as it is? <<
Conversion Cost:
>>For incompatible changes, what is the cost to users of converting existing user code? To what extent can the process be automated? How?<<
Esthetics:
>>How does this proposal affect the simplicity of the language, ease of learning, etc.<<
Discussion:
>> Additional arguments, discussions, endorsements, testimonials, etc. should go here. A blow-by-blow account of debates is not necessary. <<
∂11-Jun-87 1620 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:20:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:15:10 PDT
Date: 11 Jun 87 13:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: COMPILER-WARNING-STREAM (Version 6)
To: X3J13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-cleanup@sail.stanford.edu
Message-ID: <870611-131510-1611@Xerox>
!
Issue: COMPILER-WARNING-STREAM
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/27/87
Version 2 at committee meeting 15-Mar-87
Version 3 Masinter 15-Mar-87
Version 4 by Fahlman, incorporate Dribble
Version 5 by Masinter, 29-May-87, revert to Version 3
Version 6 by Masinter, 5-Jun-87, minor formatting
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings. If this is to be allowed, it
should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)
COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.
Rationale:
Compiler warning output is a widely accepted extension to the
compilation. Warnings that come via the WARN function will go to the
stream that is the value of *ERROR-OUTPUT*.
Current Practice:
Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.
Adoption Cost:
In most cases, the change to the compiler to redirect output is expected
to be very slight.
Benefits:
Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear where it's directed.
Conversion Cost:
Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.
The committee considered extending the proposal to describe the
interaction with DRIBBLE on the warning output, but found that DRIBBLE
was so underspecified as to make the task impossible. DRIBBLE should be
considered in a separate proposal.
The cleanup committee supports this change as stated.
∂11-Jun-87 1622 Masinter.pa@Xerox.COM Issue FORMAT-OP-C (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:21:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 14:07:51 PDT
Date: 11 Jun 87 14:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue FORMAT-OP-C (Version 5)
To: X3J13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <870611-140751-1716@Xerox>
!
Issue: FORMAT-OP-C
References: WRITE-CHAR (p384), ~C (p389)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Versions 2,3 by Pitman
5-Jun-87, Version 4 by Masinter (copy-editing)
11-Jun-87, Version 5 release to X3J13
(remove confusing paragraph)
Problem Description:
CLtL is not adequately specific about the function of the format
operation ~C. The description on p389 says that "~C prints the character
in an implementation-dependent abbreviated format. This format should be
culturally compatible with the host environment." This description is
not very useful in practice.
Presumably the authors intended the `cultural compatibility' part to
gloss issues like how the SAIL character set printed, but unfortunately
another completely reasonable (albeit unplanned) interpretation arose:
some implementations have (FORMAT NIL "~C" #\Space) => "Space" rather
than " ".
Since the behavior of ~A is also vague on characters (a separate
proposal will address this), the only way to safely output a literal
character is to WRITE-CHAR; currently, FORMAT does not suffice.
Proposal (FORMAT-OP-C:WRITE-CHAR):
Change the behavior of ~C to say that, when given a character with zero
bits, it will perform the same action as WRITE-CHAR. (This proposal
leaves the behavior of ~C with non-zero bits incompletely specified.)
For example, the description of the ~C format directive on p389 of CLTL
might read:
~C prints the character using WRITE-CHAR if it has zero bits.
Characters with bits are not necessarily printed as WRITE-CHAR
would do, but are displayed in an implementation-dependent
abbreviated format that is culturally compatible with the host
environment.
Test Case:
(EQUAL (FORMAT NIL "~C" #\Space) " ")
Rationale:
This was probably the intent of the Common Lisp designers.
It makes things clear enough that programmers can know what to expect in
the normal case (standard characters with zero bits).
Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
It seems as if the implementations which return "Space" treat ~C and ~:C
equivalently or very similarly.
Current Practice:
Implementations are divided. Some implementations have
(FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Adoption Cost:
Those implementations which did not already implement ~C as WRITE-CHAR
would require an incompatible change.
Benefits:
User code that uses ~C would have a chance of being portable. As things
stand, users who use ~C can't reliably port their code.
~C and ~:C would perform usefully distinct operations.
Conversion Cost:
Standard ``Query Replace'' technology for finding occurrences of "~C"
and changing them to "~:C" semi-automatically should suffice.
Aesthetics:
Making ~C do something well-defined will probably be perceived as a
simplification.
Discussion:
The cleanup committee generally supports this clarification.
The original version of this proposal (which tried to make WRITE-CHAR
and ~C identical in all cases) prompted the following comment:
"I believe the error in CLtL is that it was not stated explicitly that
the `implementation-dependent abbreviated format' applies only to
characters with non-zero char-bits. Thus instead of removing the
mumbling about cultural compatibility, I suggest simply adding a
sentence saying that ~C is the same as WRITE-CHAR for characters with
zero char-bits. I don't think we want to require ~C and write-char to
do the same thing for characters with bits."
∂11-Jun-87 1620 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:20:37 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 JUN 87 13:27:34 PDT
Date: 11 Jun 87 13:27 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-INITIALIZATION (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <870611-132734-1630@Xerox>
!
Issue: DEFVAR-INITIALIZATION
References: DEFVAR (p68)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/26/87
Version 2 by cleanup committee 15-Mar-87 14:45:18
Version 3 by Masinter (format) 15-Mar-87 18:34:28
Version 4 by Masinter 5-Jun-87
Problem description:
The description of DEFVAR on p.68 is not adequately clear on what
happens if an initialization value is not provided, as in (DEFVAR FOO).
Does this initialize the variable?
Proposal (DEFVAR-INITIALIZATION:CONSERVATIVE):
If the one-argument form of DEFVAR is used, the value (or lack of value)
of the variable is not changed.
Rationale:
In parent languages to CL, such behavior was documented. The omission of
clear documentation in CL is presumably an accident.
Current Practice:
Most implementations already do not initialize the variable. Some
implementations, however, assume that the missing initial value defaults
to NIL and assume that the variable is always to be initialized if
unbound.
Adoption Cost:
Some implementations suffer a minor incompatible change. The
modification to systems is presumably trivial.
Benefits:
It's sometimes useful to have the ability to declare a variable without
initializing it. More importantly, though, DEFVAR is used by lots of
users in every implementation and it deserves uniform treatment.
Conversion Cost:
It's stylistically poor to be relying on the variable to be initialized
without writing the initial value explicitly anyway. Except for very
rare situations where a conditional action is taken based on a BOUNDP
test of the variable, user programs are unlikely to be affected in
practice.
Very few user programs are likely to be affected. The incidence rate is
probably sufficiently low that the issue of automatic tools for
conversion is irrelevant.
Aesthetics:
No significant issues are obvious.
Discussion:
The cleanup committee generally supports this clarification.
[Version 3 was distributed at the last X3J13 meeting. This version has
changed only to bring it in line with the current proposal format.]
∂11-Jun-87 1619 Masinter.pa@Xerox.COM AREF-1D (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:19:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:07:01 PDT
Date: 11 Jun 87 13:06 PDT
From: Masinter.pa@Xerox.COM
Subject: AREF-1D (Version 5)
To: X3J13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870611-130701-1603@Xerox>
In most of these proposals, some earlier version was circulated to the
committee and explicitly voted on. In cases where there have been
editorial changes after the ballot, the edited version has been
circulated, but not necessarily endorsed.
!
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
02-Jun-87, Version 2 by Pitman (ROW-MAJOR-AREF)
6-Jun-87, Versions 3, 4 by Masinter (editorial)
11-Jun-87, Version 5, to X3J13 (no changes)
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying rank.
Currently, you have to make a displaced array to work with temporarily
and then throw away the displaced array when you're done. In many cases,
this is bothersome because there is no a priori reason why they should
have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF that allows one-dimensional
access to the storage backing up a given array assuming the normal
row-major storage layout.
ROW-MAJOR-AREF is valid for use with SETF.
Rationale:
Common Lisp requires row-major storage layout of arrays and has a number
of operators that allow users to exploit that order. ROW-MAJOR-AREF is a
useful, simple addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops that had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this would involve
something like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations that already use
this primitive internally, it's little more than a matter of changing
the name of or otherwise releasing the existing primitive. In some
implementations, it might involve writing a small amount of code or
compiler work to make ROW-MAJOR-AREF work efficiently.
Benefits:
This gives users efficient access to something to which they already
have inefficient access.
Conversion Cost:
This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely
to be used by any current program.
Aesthetics:
This allows certain programs to be written in a more aesthetic way.
Discussion:
The cleanup committee generally supports this enhancement. Version 2 was
endorsed (assuming change to function name ROW-MAJOR-AREF.)
∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue FORMAT-ATSIGN-COLON (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:21:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:43:40 PDT
Date: 11 Jun 87 13:40 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue FORMAT-ATSIGN-COLON (Version 3)
To: x3j13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@sail.stanford.edu
Message-ID: <870611-134340-1658@Xerox>
This was distributed at the last X3J13 meeting. The only changes have
been to bring it into the current proposal format.
!
Issue: FORMAT-ATSIGN-COLON
References: FORMAT description (p386)
Category: CLARIFICATION
Edit history: Version 1 by Pitman 02/27/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Masinter 15-Mar-87
Version 4 by Masinter 5-Jun-87
Problem Description:
CLtL describes the format op syntax as:
"a format directive consists of a tilde (~), optional prefix parameters
separated by commas, optional colon (:) and atsign (@) modifiers, and a
single character indicating what kind of directive this is."
CLtL uses :@ fairly consistently throughout without saying whether @: is
legal. Is @: allowed?
Proposal (FORMAT-ATSIGN-COLON:OK):
There is no required ordering between the @ and : modifier.
Rationale:
This is currently underspecified, and this way of specifying it will
cause the least disruption to user code.
Current practice:
Most implementations accept these in either order. Some implementations
have been known to expect only :@.
Adoption Cost:
The change to accept either syntax is probably quite trivial.
Benefits:
Having @: and :@ mean different things would be awkward.
Conversion Cost:
Existing user code would be unaffected.
Aesthetics:
Leaving these unordered is slightly simpler conceptually.
Discussion:
The cleanup committee supports this clarification.
∂11-Jun-87 1619 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 11)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:19:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:04:43 PDT
Date: 11 Jun 87 13:04 PDT
From: Masinter.pa@Xerox.COM
Subject: Format for proposals to the cleanup committee (Version 11)
To: X3J13@Sail.stanford.edu
Message-ID: <870611-130443-1598@Xerox>
The previous version went out without line breaks.
!
Format for proposals to the cleanup committee (Version 11)
June 11, 1987
Replace the text below in >> double inverted angle-brackets <<. Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upcase all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.
Issue: >>A short descriptive label, which starts with a name
which occurs in the index of CLtL, and be a suitable symbol in the
Common Lisp style, e.g., CDR-TERMINATION.<<
References: >>The pages of CLtL which describe the feature being
discussed, or other references.<<
Category: >>One or more of: CLARIFICATION -- proposal to resolve an
ambiguity or case of under-specified situation in CLtL, where this
ambiguity interferes with portability of code. CHANGE -- proposal for an
incompatible change to the language. ADDITION -- proposal for a
compatible extension to the language. <<
Edit history: >>Author and date of submission (version 1), and author
and date of subsequent versions.<<
Problem description:
>>Describe the problem being addressed -- why is the current situation
unclear or unsatisfactory? Avoid describing the proposal here or arguing
for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing. Ideally, this should take the form of
text that could be dropped into CLtL or some new specification document.
If necessary, propose a set of labelled alternatives here, rather than a
single proposal. Each proposal must be a complete design; do not leave
out details. Avoid arguing for the proposal here, just describe it.<<
Test Case:
>>When possible, give a sample of Common Lisp code that illustrates the
issue. The code should stand alone, and preferably be suitable for
incorporation in a diagnostic suite. <<
Rationale:
>> A brief argument for the proposal. (If more than one proposal is
listed, discuss each issue separately here and in subsequent
sections.)<<
Current practice:
>>Do some/many/no Common Lisp implementations already work this way?
Survey independent Common Lisp implementations - preferably three or
more.<<
Adoption Cost:
>>What is the cost to implementors of adopting the proposal? How much
implementation effort is required? Is public-domain code available? For
pervasive changes, can the conversion be automated?<<
Cost of non-adoption:
>>How serious is it if nothing is done? <<
Benefits:
>>What is better if the proposal is adopted? How serious is the problem
if just left as it is? <<
Conversion Cost:
>>For incompatible changes, what is the cost to users of converting
existing user code? To what extent can the process be automated? How?<<
Esthetics:
>>How does this proposal affect the simplicity of the language, ease of
learning, etc.<<
Discussion:
>> Additional arguments, discussions, endorsements, testimonials, etc.
should go here. A blow-by-blow account of debates is not necessary. <<
∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: IMPORT-SETF-SYMBOL-PACKAGE (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:23:32 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:20:43 PDT
Date: 11 Jun 87 15:20 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: IMPORT-SETF-SYMBOL-PACKAGE (Version 5)
To: X3J13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-Cleanup@Sail.stanford.edu
Message-ID: <870611-152043-1809@Xerox>
This issue was distributed at the last X3J13 meeting. The only changes
were to remove a sentence about INTERN (which didn't belong in this
proposal) and to put it in the current proposal format.
!
Issue: IMPORT-SETF-SYMBOL-PACKAGE
References: IMPORT (CLtL p. 186)
Category: CLARIFICATION.
Edit History: Version 2 at committee meeting 15-Mar-87 15:19:23
Version 3 by Masinter 15-Mar-87 18:42:13
Version 4 29-May-87 by Masinter, remove confusing
"to further clarify".
Version 5 to X3J13
Problem Description:
The action of IMPORT on the home package of a symbol is not described
well; does it affects the "home package" of a symbol.
Proposal (IMPORT-SETF-SYMBOL-PACKAGE:YES):
IMPORT behaves as follows: if any symbol to be imported has no home
package (SYMBOL-PACKAGE returns NIL), then IMPORT sets the home package
of the symbol to the specified package being imported to.
Rationale:
Current practice:
Most Common Lisp implementations work this way.
Adoption Cost:
small -- it requires a simple rewrite if not done this way.
Benefits:
Without this proposal, there is confusion about how Common Lisp works,
and the risks that some new implementations will not work this way.
Conversion Cost:
None, as this describes current practice.
Discussion:
The cleanup committee supports this clarification.
∂11-Jun-87 1625 Masinter.pa@Xerox.COM (REVISION) Issue: PATHNAME-STREAM (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:23:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:27:51 PDT
Date: 11 Jun 87 15:27 PDT
From: Masinter.pa@Xerox.COM
Subject: (REVISION) Issue: PATHNAME-STREAM (Version 3)
TO: X3j13@sail.stanford.edu
Line-fold: NO
CC: Masinter.pa@Xerox.COM
REPLY-To: CL-Cleanup@sail.stanford.edu
Message-ID: <870611-152751-1817@Xerox>
Version 2 of this proposal accidentally contained an odd sentence fragment under Conversion cost. Sorry.
!
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Version 3 by Masinter 11-Jun-87 (remove odd
odd sentence fragment)
Category: CHANGE/CLARIFICATION
Problem Description:
The PATHNAME function as documented in CLtL is impossible to implement. CLtL says that a stream can be used as an argument and converted to a pathname, but pathnames only name files, not other sources or sinks of data that streams might be connected to.
Proposal PATHNAME-STREAM:FILES-ONLY:
Specify that if a stream is used as a pathname, it must be a stream that is or was open to a file. For example, it is an error to attempt to obtain a pathname from a two-way-stream or a string-stream.
Rationale:
This is probably what the designers of Common Lisp intended. This is the only thing that can be implemented without large changes to the language such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname. Others may do something else, but since the proposal is to define this to be "is an error", current practice seems irrelevant.
Adoption Cost:
Since the proposal says only "is an error" rather than "signals an error", no implementations need change.
Benefits:
Description of pathname functions will make more sense.
Conversion Cost:
None.
Aesthetics:
Makes language a little cleaner.
Discussion:
The cleanup committee supports this clarification.
∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:23:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:06:30 PDT
Date: 11 Jun 87 15:06 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 2)
TO: X3j13@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
REPLY-To: CL-Cleanup@sail.stanford.edu
Message-ID: <870611-150630-1795@Xerox>
!
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Category: CHANGE/CLARIFICATION
Problem Description:
The PATHNAME function as documented in CLtL is impossible to implement.
CLtL says that a stream can be used as an argument and converted to a
pathname, but pathnames only name files, not other sources or sinks of
data that streams might be connected to.
Proposal PATHNAME-STREAM:FILES-ONLY:
Specify that if a stream is used as a pathname, it must be a stream that
is or was open to a file. For example, it is an error to attempt to
obtain a pathname from a two-way-stream or a string-stream.
Rationale:
This is probably what the designers of Common Lisp intended. This is the
only thing that can be implemented without large changes to the language
such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname.
Others may do something else, but since the proposal is to define this
to be "is an error", current practice seems irrelevant.
Adoption Cost:
Since the proposal says only "is an error" rather than "signals an
error", no implementations need change.
Benefits: Description of pathname functions will make more sense.
Conversion Cost: We believe no existing user code relies on any values.
Aesthetics: Makes language a little cleaner.
Discussion: The cleanup committee supports this clarification.
∂11-Jun-87 1622 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:22:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 14:18:53 PDT
Date: 11 Jun 87 14:18 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 4)
To: X3J13@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <870611-141853-1738@Xerox>
!
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter
(no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
Version 2 29-May-87, extracted again
Version 3 5-Jun-87, by Masinter
Version 3 11-Jun-87, for release
Problem Description:
If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed
explicitly to denote the null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Clarify that MACROLET, FLET and LABELS can shadow a SETF method; i.e., a
SETF method applies only when the global function binding of the name is
lexically visible.
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although
some do not. One implementation has extended GET-SETF-METHOD to take an
optional argument which is incompatible with this use.
Adoption Cost:
Some implementations will have to add this feature, although it is not a
major change.
Benefits:
This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.
Conversion Cost:
This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a user's program is
very small.
Aesthetics:
SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct.
Discussion:
The cleanup committee generally supports this change.
A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common
Lisp Object System) and should be addressed by a future proposal. For a
while, the cleanup committee attempted to deal with these issues
together, but decided to separate them out into their component parts.
This issue is the simplest.
∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:21:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:43:23 PDT
Date: 11 Jun 87 13:37 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FLET-IMPLICIT-BLOCK (Version 6)
TO: X3J13@sail.stanford.edu
reply-To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870611-134323-1657@Xerox>
!
Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Category: OMISSION
Edit history: Version 2 by cleanup committee 15-Mar-87 15:13:33
Version 3 by Masinter (reformatting) 7-Apr-87 17:49:12
Versions 4,5 by Fahlman 11-Apr-87
Version 6 by Masinter 5-Jun-87
Problem Description:
Do FLET, LABELS, DEFMACRO, MACROLET, DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE have an implicit block around their bodies like the body of a
DEFUN? CLtL is silent on this point. Many users and some implementors
assume that such blocks should be established, since they view these
forms as analogous with DEFUN.
Test case:
(defun test ()
(flet ((test (x) (if x (return-from test 4) 3)))
(list (test nil) (test t))))
(test)
will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would
return 4 in an implementation that did not add an implicit block around
FLET.
Proposal: FLET-IMPLICIT-BLOCK:YES
Each function created by FLET and LABELS and each macro created by
DEFMACRO and MACROLET has an implicit block around the body. The name
of this block is that same as the (lexical) name of the function or
macro. Similarly, the body code in DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE is surrounded by a block with the same name as the accessor or
type.
Current Practice:
Current practice is mixed. Several implementations do not add the
implicit block, others do, some add some of these blocks and not others.
Cost of adopting this change:
Some implementations will have to be modified. This should be a
relatively easy modification.
Cost of not adopting the change:
If the issue is not clarified one way or another, continuing confusion
will result in portability problems. Clarifying the issue in any other
way would also require modifications in some implementations.
Cost of converting existing code:
It is possible that some user code would break because it does a return
from within a code body to an outer block that has the same as the
newly-required block. Such problems will be rare, and the code in
question would not run on all current Common Lisp systems because of the
diverse interpretations currently in effect. It would be possible to
detect all such instances automatically, though it seems unlikely that
anyone will need to use this technique.
Discussion:
The goal is first to clean up an ambiguous situation and, second, to do
this in a way that provides consistent behavior between local and global
definitions. The proposed change would allow a simple rule of thumb:
any named entity that takes a code body establishes an implicit block
with the obvious name.
Two alternatives to the proposal were considered and rejected:
The first would be to keep the implicit block in DEFUN, and to clearly
state that the other forms do not create implicit blocks. This violates
the goal of consistency between lexical and global definitions, and it
seems to conflict with users' expectations.
The second alternative was to eliminate the implicit block from DEFUN
rather than adding such blocks to other forms. There was some feeling
that specifying the implicit block in DEFUN was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself. If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.
However, eliminating the implicit block in DEFUN would be a significant
incompatible change. Some users find this implicit block to be a great
convenience for popping out of convoluted code, and some existing code
makes heavy use of this feature. While such code could be repaired
automatically by searching for situations in which the user returns from
a function by name and by adding an appropriate explicit block to any
function containing such a forms, it would still require more more work
on existing user code than this proposal made above.
There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common in future Common Lisp
implementations. The outcome of these discussions was general agreement
that a compiler could easily eliminate the implicit block in any case
where it is not actually used, and that the impact on tail-recursion
optimization in compiled code is therefore minimal.
∂11-Jun-87 1842 Masinter.pa@Xerox.COM Issue: PRINC-CHARACTER (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 18:42:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:35:38 PDT
Date: 11 Jun 87 15:35 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PRINC-CHARACTER (Version 2)
TO: X3J13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Reply-to: CL-cleanup@sail.stanford.edu
Line-fold: NO
Message-ID: <870611-153538-183@Xerox>
!
Issue: PRINC-CHARACTER
References: PRINC (p383)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Version 2 by Pitman (removed FORMAT-OP-C)
Problem Description:
CLtL is not adequately specific about the function of PRINC
when given a character as an argument.
For example, does (PRINC #\Space) print ``Space'' or `` ''?
The advice that "the general rule is that output from PRINC is
intended to look good to people" is the root of a lot of the problem.
The truth is that what looks good varies with context. viz,
* For (FORMAT NIL "Foo~ABar" #\Space)
Pretty result: "Foo Bar"
Ugly result: "FooSpaceBar"
In other words, " " looks better here.
* For (FORMAT T "Type ~C to continue" #\Space)
Pretty result: "Type Space to continue"
Ugly result: "Type to continue"
In other words, "Space" looks better here.
Proposal (PRINC-CHARACTER:WRITE-CHAR):
(PRINC char stream) should be defined to be equivalent to
(WRITE-CHAR char stream).
Rationale:
The behavior of (PRINC char) should be well-defined even if a
completely arbitrary decision had to be made.
In fact, though, we can get some advice by appealing to history.
The only data type which corresponds to characters in most old
lisps was symbols. For example, in Maclisp,
(PRINC char-symbol) == (TYO (GETCHARN char-symbol 1))
In Common Lisp, it would make sense in the absence of arguments
to the contrary to preserve an analagous relation, namely:
(PRINC char) == (WRITE-CHAR char)
Current Practice:
Vaxlisp, Symbolics, Spice Lisp, and Lucid all print " " and not
"Space" for (PRINC #\Space).
Symbolics and Spice are known to use the WRITE-CHAR strategy.
Vaxlisp and Lucid might be using it, too, or they might be
using ~C in FORMAT; no one familiar with their internals has
commented.
In any case, some other implementations are believed to differ
(ie, to output "Space" when you PRINC a #\Space), but a specific
reference is not currently available. In any case, the wording
in CLtL is not clear enough to preclude such a differing
implementation from `legitimately' emerging.
Adoption Cost:
Any implementations which did not already implement this proposal
decided upon would suffer an incompatible change.
Benefits:
User code that uses PRINC (and presumably ~A) on characters would
have a chance of being portable.
Conversion Cost:
It's easy to search for occurrences of PRINC and ~A in code, but
it may not always be apparent when the argument is a character.
Automatic conversion is unlikely to succeed.
Aesthetics:
Making PRINC do something well-defined for as many primitive data
types as possible will probably be perceived as a simplification.
Discussion:
The cleanup committee generally supports this proposal.
Pitman thinks this is moderately important because it is embarrassing
to have commonly used functions like this vary so widely in behavior
between implementations. He doesn't think it is critical because
(if nothing else) it is only one of many problems with the vague
contract of PRINC.
There was an alternate proposal PRINC-CHARACTER:FORMAT-OP-C which
suggested making PRINC work like ~C in FORMAT, but no one seemed
to think that was useful and the proposal was removed for Version 2
to keep from muddying what's likely to be a very straightforward
vote in favor of PRINC-CHARACTER:WRITE-CHAR.
∂15-Jun-87 1920 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jun 87 19:20:03 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUN 87 14:43:28 PDT
Date: 15 Jun 87 14:15 PDT
From: Masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
cc: Masinter.pa@Xerox.COM
Message-ID: <870615-144328-103@Xerox>
!
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
5-Jun-87, Version 5 by Masinter
11-Jun-87, Version 6 by Masinter
Problem Description:
CLtL says that only keyword symbols can be used as non-positional
argument names in &key parameter specifiers.
As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of non-positional argument names;
allow any symbol. That is:
If, following an &KEY, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword-symbol with the same print name as the variable is created and
is used as the keyword-indicator in function calls. The only way to get
a non-positional-argument-name that is not a keyword symbol is to use
the (indicator variable) syntax in the function's lambda list. The
keyword-indicator can be any symbol, not just a keyword.
Test case:
(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
non-positional argument names to be symbols, and not allowing numbers,
but does not speak to the issue of whether or not those symbols should
be further restricted to be keywords.
The desire for non-positional arguments whose names are not keyword
symbols arises when the set of non-positional arguments accepted by a
function is the union of the sets of non-positional arguments accepted
by several other functions, rather than being enumerated in a single
place. In this case, it becomes desirable to use packages to prevent
accidental name clashes among non-positional argument names of different
functions.
One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS). It will have generic functions that accept non-positional
arguments and pass them on to one or more applicable methods, with each
method defining its own set of arguments that it is interested in. If
this proposal is not adopted, either the non-positional argument names
will be required to be keywords, which will require the methods to have
non-modular knowledge of each other in order to avoid name clashes, or
the methods will have to be defined with an ad hoc mechanism that
duplicates the essential functionality of &key but removes the
restriction.
A second example of a Common Lisp application that requires this
capability is private communication channels between functions. Suppose
a public routine MAKE-FOO needs to accept arbitrary keywords from the
caller and passes those keywords along to an internal routine using
keywords of its own.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override some keyword in keyword-value-pairs, since the only way that
could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL),
or if the user was programming explicitly in the FOOLAND package, either
of which is an implicit admission of willingness to violate FOOLAND's
modularity.
Documentation Impact:
The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in
understanding the impact of the proposal.
The wording which refers to non-positional arguments as being introduced
by keyword symbols wuuld change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each -keyword- must be a symbol.
The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.
Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as non-positional argument
names, and that all functions built into the Common Lisp language follow
that convention.
Examples would be useful. On p.64 the following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)
Adoption Cost:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Benefits:
This will help with the object-oriented programming standard, among
other things.
Conversion Cost:
None--no existing programs will stop working.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is more
esthetic or less esthetic than the freedom, but in either case the
aesthetic effect is slight.
In any case, users who do not want to use the extended functionality can
generally avoid it.
Discussion:
The cleanup committee generally supports this extension.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
The cleanup committee considered, but did not adopt, a proposal to
exclude NIL as a legal indicator. It might catch some errors, but is
otherwise an odd restriction.
∂16-Jun-87 2337 Masinter.pa@Xerox.COM
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87 23:36:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 17:17:44 PDT
Date: 16 Jun 87 17:17 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.Edu
Message-ID: <870616-171744-109@Xerox>
This is the cover letter for the various proposals which have been
mailed to you. Hardcopy versions of all proposals will go out in
tomorrow's (U.S.) mail.
!
Dear X3J13 member:
Enclosed are several proposals from the cleanup committee for your
examination. The committee has been working hard via electronic mail.
For each proposal, there has been an average of 10-15 messages.
In most cases, the cleanup committee has explicitly endorsed the
proposal--i.e., we all think it is a good idea. In some cases, while we
generally agreed that the proposal is a good idea, we've wrangled over
the exact wording of the proposal and the discussion; in those cases,
while an earlier version was circulated among the cleanup committee, the
latest version is the sole responsibility of the author. In a few cases
(identified in the proposal) there has been disagreement on the proposal
itself, but we believed we should bring the matter to the attention of
the larger group, for discussion and guidance.
Listed below are all of the issues currently under consideration, with
an extremely brief description of the issue. If you want further
details, or want to join the cleanup committee, please let us know
(CL-CLEANUP@Sail.Stanford.edu). Issues whose writeup is included in
this mailing (and mailed electronically) are marked with a !. Issues
marked with * are nearly ready for release, but a final version is not
available. We hope to have versions of these at the X3J13 meeting.
!
! Proposal format (Version 11)
Format for proposals to the cleanup committee.
Version 11 released 11-Jun-87.
* ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Discussion about :displaced-to nil vs. no :displaced-to.
Not ready for release.
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
Several comments which need reply
Not ready for release.
! AREF-1D (Version 5/11 Jun 87)
(Add a new function for accessing arrays with row-major-index)
Version 5 released
ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
(Extend ASSOC-IF, etc. to allow :KEY)
Almost ready for release.
COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
Questions on interaction with condition proposal.
Is this an environment issue?
Not released.
! COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 3 released.
Version 6 released 11-Jun-87.
! DEFVAR-INITIALIZATION (Version 4)
((DEFVAR var) doesn't initialize)
Version 3 Released
Version 4 released 11-Jun-87.
! DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 released 11-Jun-87.
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available?
Not ready for release.
EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE)
Not ready for release.
FILE-WRITE-DATE-IF-NOT-EXISTS
(What does FILE-WRITE-DATE do if no such file?)
Defer to condition system?
In discussion, formal proposal not yet submitted.
! FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 released 11-Jun-87.
! FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
( @: == :@ in format)
Version 3 released.
Version 4 (re-)released 11-Jun-87.
* FORMAT-COMMA-INTERVAL (Version 1/10 June 87)
(Allow another argument to ~D etc to paramerize digits between commas)
Almost ready for release.
FORMAT-NEGATIVE-PARAMETERS
In discussion, formal proposal not yet submitted.
! FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Version 5 released 11-Jun-87.
! FUNCTION-TYPE (Version 5/ 16-Jun-87)
(Change definition of FUNCTIONP, function type ...)
Draft released 16-Jun-87.
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
Not ready for release.
! GET-SETF-METHOD-ENVIRONMENT (Version 4, 11-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 released 11-Jun-87.
! IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Pitman will release as report from cleanup + error committee.
! IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
(Does IMPORT affect home package?)
Version 3 Released
Version 5 released 11-Jun-87.
! KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun)
( &KEY arguments not in keyword package?)
Version 6 released 15-Jun-87.
LOAD-TIME-EVAL (Version 1, 6 Jun 87)
(New function/macro/special form for evaluation when
compiled file is loaded?)
Not ready for release.
MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
From ENVIRONMENT-ARGUMENTS
Formal proposal not yet submitted.
! PATHNAME-STREAM (Version 2)
(PATHNAME only works on file streams)
Released 11-Jun-87.
PATHNAME-SYMBOL (Version 2)
(Do symbols automaticly coerce to pathnames?)
Not ready for release.
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
(character interaction with echoing on terminal)
Not ready for release.
! PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Released 11-Jun-87.
PROCLAIM-LEXICAL (Version 1)
(add LEXICAL proclaimation, default binding type for
undeclared free variables)
Not ready for release.
PROMPT-FOR (Version 1)
(add new function which prompts)
Not ready for release.
PUSH-EVALUATION-ORDER
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
In discussion, formal proposal not yet submitted.
REQUIRED-KEYWORD-ARGUMENTS
(Syntax for keyword arguments which must be supplied?)
In discussion, formal proposal not yet submitted.
REMF-DESTURCTION-UNSPECIFIED (Version 1)
(How does REMF affect its arguments?)
Not ready for release.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
In discussion, no clear consensus
Not ready for release.
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Not ready for release.
SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Not ready for release.
SHARPSIGN-PLUS-MINUS-PACKAGE
(What package are *features* in?)
Not ready for release.
SPECIAL-FORM-SHADOW
(Is it OK to shadow a special form with FLET, LABELS?)
In discussion, no formal proposal submitted.
TAILP-NIL
(Operation of TAILP given NIL)
Not ready for release.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
(GO out of UNWIND-PROTECT clauses.)
Not ready for release.
∂16-Jun-87 2336 Masinter.pa@Xerox.COM Issue: IF-BODY (Version 7)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87 23:36:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 17:07:38 PDT
Date: 16 Jun 87 17:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: IF-BODY (Version 7)
to: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <870616-170738-108@Xerox>
The cleanup committee had a great deal of difficulty attempting to
arrive at a version of this proposal which fairly outlined the issues.
I don't think we succeeded. While the issue itself is straightforward,
the way in which it came about, our procedures for handling
controversial cases, the manner in which summaries of opinions get
generated, etc. have been problematic. Hidden within this simple issue
are some more complex ones, with tradeoffs between compatibility and
extensions, simplicity and ease of use. As it stands, while we have
discussed reviewed numerous versions of this proposal, this version has
not been approved or endorsed by the cleanup committee as a whole.
Larry Masinter
!
Issue: IF-BODY
References: IF (p115)
Category: ENHANCEMENT
Edit history:27-Feb-87, Version 1 by Pitman (IF-BODY:YES)
3-Mar-87, Version 2 by Fahlman (add IF-BODY:NO)
17-Apr-87, Version 3 by Masinter(merge 1&2)
19-Apr-87, Version 4 by Pitman (misc editing)
27-Apr-87, Version 5 by Pitman (for balance)
13-Jun-87, Version 6 by Pitman (for brevity)
16-Jun-87, Version 7 by Masinter(for brevity)
Problem Description
CLtL defines the special form IF as taking either two or three
arguments. Some implementations extended IF to allow more arguments. In
those implementations, using the extended IF syntax will not generate a
warning. Code using the extended IF is not portable.
Proposal (IF-BODY:LEGAL):
Extend IF, making it expressly legal to supply an implicit-PROGN of
`else' forms using the syntax (IF test then {else}*).
Test Case:
(IF NIL 'THEN 'ELSE 'MORE)
according to CLtL is an error. Under IF-BODY:LEGAL, this would return
MORE.
Rationale:
This extension is convenient to use and is compatible with many current
implementations.
Current Practice:
According to CLtL, the test case, (IF NIL 'THEN 'ELSE 'MORE) "is an
error".
Some implementations already provide the proposed extension.
A few implementations provide alternate keyword-driven extensions that
are incompatible with the proposed extension.
Some implementations signal an error if other than two or three
arguments are passed.
Some implementations quietly ignore additional arguments to IF,
returning only the value of the third argument when the first argument
is false.
Benefits:
As long as some implementations provide this extension while others do
not, the portability goals of Common Lisp will suffer. Code developed
where these features are available is not typically discovered to be in
error until a port to some other implementation is attempted. At that
point, which is typically inconveniently late in the development cycle,
the developer may notice that code either does not compile (generates
syntax errors) or does not compile correctly (the additional forms are
quietly ignored and the code generated is not what the writer intended).
The problem is rightly due to the user, but users typically expect that
they should be warned about such problems. Unfortunately, however, both
the Lisp which allows the extended syntax and that which fails to signal
an error about the invalid syntax are within their rights as currently
stated.
It is not adequate to encourage implementors to warn about non-standard
uses since the only implementations which will implement the extension
are ones who think it is a good idea to use the feature, and people are
not inclined to warn about things they think are a good idea to use.
Adoption Cost:
In most implementations which don't already have this extension, making
this syntax legal is a matter of a fairly localized change to a finite
number of utilities which reason about programs (compiler, interpreter,
code walkers).
In some implementations which have incompatible extension strategies,
such as keyword-driven facilities, the cost may be slightly higher
because this is an incompatible change.
Aesthetics:
This issue has both pro and con sides. Opinions differ on how important
each of these arguments are. The following arguments have been made:
Pro: When there are multiple else clauses, the alternatives (IF test
then (PROGN else1 else2)) or (COND (test then) (T else1 else2 else3))
are cumbersome. A natural extension of IF provides economy of expression
in some circumstances. Experience in user communities where extended IF
is available show that few users object to its presence; most are happy
about the syntactic flexibility it provides. By allowing the extended
IF, the resolution of this controversial programming style issue is left
to the user rather than being forced by the language designers. Those
who prefer the symmetry of the (IF test then else) syntax are free to
use it as needed or even exclusively without infringing on the desires
of others who may wish to use the extended syntax.
Con: The (IF test then else) syntax is symmetric. The asymmetry of (IF
test then {else}*) syntax can be visually confusing. IF was intended to
be the simplest conditional form, from which all the others are built.
This proposal makes it more complex.
Discussion:
The cleanup committee had a great deal of difficulty with this issue,
primarily because of the many conflicting priorities it seems to
represent. It prompted a great deal of debate.
The committee found it nearly impossible even to arrive at a version of
the problem statement and proposal which could be endorsed as a fair
representation of the issue. In particular, this version has not been
endorsed or agreed upon by all members the committee.
Some members feel very strongly that this proposal should be adopted,
while others object violently, not only to the proposal but to the
manner in which it arose. How can we balance flexibility against
simplicity in the language syntax? How seriously should we consider
compatibility with current extensions to Common Lisp?
The problem with IF-BODY arose as a serious compatibility issue in
porting a major Common Lisp application (MACSYMA).
There was strong sentiment that the allowed variance of IF is a serious
barrier to portability, and wants to see it fixed. Those who support
this proposal believe it is the minimally disruptive way to fix the
problem. If this proposal is not accepted, it should be mandated that
extensions to IF are explicitly disallowed. The status quo, where there
is a tacit acceptance of extensions which are not portable and difficult
to detect, is unacceptable.
There was concern about the potential precedent which could be set by
using compatibility concerns as a lever to introduce all kinds of
unwanted idiosyncratic extensions present in a few implementations.
It was suggested that the mere fact that some people like an extensionis
not sufficient reason to put it into the language, but is sufficient
reason to -discuss- putting it into the language.
It was noted that one of the original reasons for including IF in the
language was to have a simple primitive that can easily be recognized,
by people and by program-walkers alike, as being the simplest
conditional and not having implicit PROGNs as do WHEN, UNLESS, and COND.
The supporters argue that the language is already so cluttered that
worrying about such a tiny change to IF is unwarranted (e.g., consider
the complexity of LAMBDA). If the only concern was primitive simplicity,
we should just redefine the layer at which simplicity is achieved by
letting LISP:IF be a macro that expands into PRIMITIVE:IF which has
simpler semantics but which no one has to be stuck programming with (if
they don't want to). While users could make their own JDOE:IF macro that
has this extension, this is likely to be a such a common extension, it
should be adopted as part of the standard.
∂16-Jun-87 2336 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87 23:36:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 15:51:21 PDT
Date: 16 Jun 87 15:33 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
Reply-to: CL-Cleanup@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870616-155121-101@Xerox>
FUNCTION-TYPE is one of the more difficult issues facing the cleanup
committee. This is a tough but important issue that involves some
fundamental trade-offs, so discussion by the whole X3J13 committee is
called for.
I am distributing version 5, even though the full cleanup committee has
not read or commented on it. Scott Fahlman worked hard to produce
Version 5; I think Scott's summary of the issues and arguments is
excellent. However, to repeat, because of insufficient time, this
proposal does not reflect a consensus of opinion, either on the proposal
or on the form in which it is presented.
This version presents the two options the committee discussed the most
as alternatives. We hope to be able to discuss (and revise) this
proposal before the Boston meeting. The proposal has two parts, one
less controversial than the other. It is possible that the group will
decide to postpone the difficult issues and just vote on the simpler
one.
The writing up of these two options was not meant to preclude others.
One other proposal was discussed, which would require a symbol's
function cell to accept symbols and lambda expressions as well as true
functions and to return unchanged whatever was put there. We do not yet
have an exposition of this point of view.
Since Scott Fahlman won't be at X3J13, he included his own position at
the end.
Sincerely,
Larry Masinter
!
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
SYMBOL-FUNCTION (pg 90), APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by Gabriel 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Fahlman 10-May-87
Version 4 by Masinter 29-May-87 incorporate comments
Version 5 by Fahlman 15-June-87 include two options
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function data type into the CLOS class hierarchy.
At present, it is not the case that (FUNCTIONP x) is equivalent to
(TYPEP x 'FUNCTION), because the latter form is illegal under a strict
reading of the manual. On page 47 it is stated that the FUNCTION type
specifier can only be used for declaration and not for discrimination.
Some of the original Common Lisp designers maintain that this
restriction on the use of the FUNCTION specifier was meant to apply only
to long-form FUNCTION specifiers. In any event, this issue blurs
the status of the FUNCTION data-type.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
Two alternative proposals are presented here:
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION and INTERPRETED-FUNCTION. Note that this is a change
from the current Common Lisp definition which explicitly defines a
COMPILED-FUNCTION type. This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
2. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. FUNCALL and APPLY will now accept only a true function as the
functional argument. This restriction is inherited by MAPCAR and other
functions in Common Lisp that take a functional argument suitable for
FUNCALL or APPLY. It is no longer legal to pass a symbol or lambda
expression as the functional argument to any of these functions; to do
so "is an error".
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears.
Specifically, it is an error to use the FUNCTION special form on a
symbol that denotes a macro or special form. (Some implementations may
choose not to signal this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.
6. The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Where CLtL says "a definition that is a
lambda-expression", substitute "a definition from which the
implementation is able to reconstruct a lambda-expression".
Proposal FUNCTION-TYPE:COERCING-REDEFINITION
This is identical to FUNCTION-TYPE:STRICT-REDEFINITION except for
section 3:
3. The text descriptions of FUNCALL, APPLY, MAPCAR and other functions
in Common Lisp which take functional arguments are modified to state
they will accept (true) functions, symbols, or lists that represent
lambda-expressions. A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used. Note that this is not a change to the current behavior of
Common Lisp; the descriptions must be changed to accommodate the new
definition of the FUNCTION data type.
RATIONALE:
Both proposals provide a clean, useful definition for the FUNCTION
data-type in Common Lisp. Under the current definition, FUNCTIONP is
nearly useless, since it is defined to be true of all symbols, including
those that do not have functional definitions.
The STRICT-REDEFINITION proposal consistently uses the new, strict
definition of FUNCTION in all of the obvious places.
The COERCING-REDEFINITION proposal cleans up the definition of the
FUNCTION data type, but attempts to minimize the impact on existing code
by providing implicit coercions in FUNCALL and APPLY.
Current Practice:
Current Common Lisp implementations vary in the way they handle
FUNCTIONP and TYPEP of FUNCTION. They also vary in what they will allow
to be put into a SYMBOL-FUNCTION cell. No current Common Lisp
implementation has exactly the semantics described in either of these
proposals, however.
Adoption Cost:
For either proposal, the type predicates would have to be brought into
compliance, but that should require little effort.
Compiled functions are true functions in almost all current
implementations, but in some implementations interpreted functions and
closures are represented as lists. Such lists would have to be changed
to structures or to some special internal data type. The behavior of
COMPILE, STEP, TRACE, and possibly ED would have to be modified
to deal with functions that are not lists (but from which the list form
can be easily reconstructed if necessary).
If STRICT-REDEFINE is adopted, implementations may choose to convert
FUNCALL and APPLY to the new stricter form, but they are not required to
do so. Since the use of a symbol or lambda expression in place of a
function "is an error", an implementation may handle these cases as a
local extension. Most implementations that continue to provide the
coercion will at least want to install an optional warning in FUNCALL
and APPLY to flag the use of this non-portable feature in user code.
BENEFITS:
By resurrecting FUNCTION as a useful concept, this proposal (either
version) will eliminate a lot of confusion and will make it easier to
talk about situations in which (true) functions are passed around as
Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes. It
also brings Common Lisp into closer alignment with Scheme.
CONVERSION COST:
The COERCING-REDEFINITION proposal attempts to minimize the impact on
user code by allowing APPLY, FUNCALL, and related functions to accept
symbols and lambda lists, as they currently do. One impact on
user-level code would be a change in the operation of certain type
predicates. Such cases should be relatively easy to find and fix.
The STRICT-REDEFINITION proposal would require some additional changes
to user code. An explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all. One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
Users might also convert their code by running for a time in an
implementation that still does the coercion in FUNCALL and APPLY, but
that issues a warning message whenever the coercion is actually needed.
This will flag all of the non-portable situations in parts of the
program that have actually been executed during the test period.
In some current Common Lisp implementations, SETF of SYMBOL-FUNCTION
will accept a symbol or lambda expression and SYMBOL-FUNCTION will
return this item unchanged. If a symbol FOO is used as the functional
definition of BAR, then any change to FOO will affect BAR as well. Some
old code (MACSYMA is one example) depends on this behavior and would
have to be modified if either of these proposals is adopted. However,
such code is not currently portable because many existing Common Lisp
implementations already violate these assumptions. CLtL does not
clearly state what values SETF of SYMBOL-FUNCTION will accept and how
that object may be modified.
Under either proposal, user code which uses COMPILED-FUNCTION-P would no
longer be valid or portable.
AESTHETICS:
Making the concept of a function well-defined will probably be perceived
as a simplification.
The STRICT-REDEFINITION proposal is perceived by most members of the
cleanup committee as the simpler and cleaner of the two proposals. The
COERCING-REDEFINITION proposal adds some complexity in the name of
compatibility.
DISCUSSION:
This has been discussed at great length within the cleanup committee.
All of us agree that the definition of the FUNCTION data type must be
revised, but there is no clear consensus on what to do about the
coercions. Since the cleanup of the type hierarchy is important to the
CLOS group, there is some urgency to this part of the proposal, at
least.
Some committee members (Gabriel and Fahlman) have argued that the strict
form of the proposal is preferable because it is simpler: it defines a
FUNCTION data type and then requires every object used as a function to
be a FUNCTION. The strict proposal requires a somewhat greater
conversion effort for user code, but it seems better to make this effort
once than to live forever with runtime coercion of functional arguments
and the resulting complexity.
Members of the Eulisp group have argued strongly for what amounts to the
STRICT-REDEFINITION proposal. They feel that this would remove one
important difference between their view of Lisp (similar to Scheme in
this instance) and ours.
Moon has argued that the coercing form of the proposal is no more
complex than the strict form; it is all a matter of taste.
Several members of the committee argued in favor of presenting both
proposals to X3J13, since the tradeoff between simplicity and conversion
effort must be discussed by the whole community.
White suggested that if the coercing version of the proposal is
adopted, we might need an APPLICABLE-P predicate that is true of any
object that is legal as a functional argument to APPLY and FUNCALL.
FUNCTIONP will not do this job.
Pitman has argued that items 4 and 5 (either proposal) will break a lot
of code that depends on being able to use lambda expressions and symbols
as function definitions, and that it will be hard to fix such problems.
He may produce a third proposal before the X3J13 meeting that deals with
these problems. He has suggested that we may wish to settle the type
redefinition issues (points 1 and 2 above) now, while deferring a
decision on the more controversial coercion issues.
Fahlman feels that the issues are now clearly drawn and that we should
go ahead and make a decision on the whole package.
Clinger has suggested that the strict form is preferable because it
makes
it possible to reduce the total size of a delivered application program.
Only those Common Lisp functions that are actually called need to be
included, but implicit function coercions tends to create loopholes
through which *every* function might be called.
The cleanup committee believes that the definition of COMPILE needs
clarification, but that it should be done in a separate proposal. The
change to COMPILE in this proposal is the minimum necessary.
Fahlman and Gabriel support FUNCTION-TYPE:STRICT-REDEFINITION.
∂17-Jun-87 0844 barmar@AQUINAS.THINK.COM Issue: FUNCTION-TYPE (Version 5)
Received: from [192.5.104.1] by SAIL.STANFORD.EDU with TCP; 17 Jun 87 08:44:15 PDT
Received: from POLYCARP.THINK.COM by AQUINAS.THINK.COM via CHAOS with CHAOS-MAIL id 32813; Wed 17-Jun-87 11:46:53 EDT
Date: Wed, 17 Jun 87 11:40 EDT
From: Barry Margolin <barmar@AQUINAS.THINK.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: CL-Cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <870616-155121-101@Xerox>
Message-ID: <870617114008.1.BARMAR@POLYCARP.THINK.COM>
I think STRICT-REDEFINITION is reasonable, although I think I would
probably vote for COERCE-REDEFINITION because it has less impact on
existing code.
The STRICT-REDEFINITION proposal would require some additional changes
to user code. An explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all. One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
There is also a big hole in STRICT-REDEFINITION as currently proposed.
This paragraph suggests that one might coerce a symbol or lambda list to
a function at runtime, but the proposal doesn't mention any new function
that one would call to do this. There needs to be a MAKE-FUNCTION
function, which takes a symbol or lambda list and returns the
corresponding function. It probably should have an optional environment
argument, too. It might be equivalent to
(defun make-function (thing &optional env)
(eval `(function ,thing) env))
However, it should probably be a primitive so that implimentations can
do it optimally.
barmar
∂17-Jun-87 1150 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 11:50:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 17 Jun 87 14:49:41-EDT
Date: Wed, 17 Jun 1987 14:49 EDT
Message-ID: <FAHLMAN.12311274316.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: X3J13@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
In reply to: Barry Margolin <barmar at AQUINAS.THINK.COM>
There is also a big hole in STRICT-REDEFINITION as currently proposed.
This paragraph suggests that one might coerce a symbol or lambda list to
a function at runtime, but the proposal doesn't mention any new function
that one would call to do this. There needs to be a MAKE-FUNCTION
function, which takes a symbol or lambda list and returns the
corresponding function. It probably should have an optional environment
argument, too. It might be equivalent to
(defun make-function (thing &optional env)
(eval `(function ,thing) env))
However, it should probably be a primitive so that implimentations can
do it optimally.
I see no big hole here.
The coercion is so trivial that I figured anyone writing a package to
convert old code to run under the STRICT-REDEFINITION rules could figure
out how to do it with no problem. And since this is a temporary crutch
for use on onconverted old code, I certainly don't think that we want to
add anything like MAKE-FUNCTION to the language; for all new code, users
will invoke FUNCTION for themselves in the appropriate places.
We do NOT want to add an environment argument to MAKE-FUNCTION. APPLY
and FUNCALL currently interpret symbols and lambda expressions in the
null lexical environment, not the surrounding one. That must be the
case, since the symbol or lambda may have come from some very different
part of the program.
Here's the way I would re-code APPLY, using a macro. FUNCALL, et al,
would be treated in a similar way. The covnersion tool would simply be
a code-walker (or perhaps even an editor macro) that turns every APPLY
into COERCING-APPLY unless the argument being passed in is sitting right
there and its type can be determined at conversion time.
(defmacro coercing-apply (funarg &rest other-args)
`(apply (let ((x ,funarg))
(typecase x
(function x)
(symbol (symbol-function x))
(t (eval (list 'function x)))))
,@other-args))
Assuming that the implementation has a good implementation of TYPECASE
and a quick test for the FUNCTION data type, this should add very little
extra cost to the APPLY call, except in the case where a raw lambda-list
needs to be function-ized. Some smart compilers may optimize away a
TYPECASE statement if the type of the object can be determined by
analysis at compile time.
Note that COERCING-APPLY is almost identical to what APPLY would look
like in the coercing version of the proposal, except that the
type-dispatch and coercion is outside the APPLY rather than inside.
Anyone arguing that the strict form of the proposal is unacceptable
because this fully-mechanized method of conversion introduces
inefficiency should realize that this same inefficiency is currently
built into *every* FUNCALL and APPLY, and would continue to be under the
coercing version of the proposal. Under the strict form, it only
appears in mechanically converted code, and then only in cases where the
type of the functional argument is not easily determined at
conversion/compile time. But I think that the overhead is so small
compared to an APPLY-type function call that efficiency is not a strong
argument for either side.
If code size is a bigger issue than the speed of APPLY, COERCING-APPLY
could be coded as a function rather than as a macro, or it could be done
as an inline function, letting the user control the tradeoff via
declarations. There are very few programs around in which the code size
would grow by more than 1%, even in the macro case.
So, fully mechanized conversion of old code is feasible under the
STRICT-REDEFINITION proposal. The question is whether we are willing to
accept even this small inconvenience in order to get a cleaner language
(if indeed you believe that the strict form is cleaner).
-- Scott
∂17-Jun-87 1247 barmar@Think.COM Issue: FUNCTION-TYPE (Version 5)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 17 Jun 87 12:46:48 PDT
Received: from polycarp by Think.COM via CHAOS; Wed, 17 Jun 87 15:49:07 EDT
Date: Wed, 17 Jun 87 15:47 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: Scott E. Fahlman <Fahlman@c.cs.cmu.edu>
Cc: X3J13@sail.stanford.edu
In-Reply-To: <FAHLMAN.12311274316.BABYL@C.CS.CMU.EDU>
Message-Id: <870617154704.1.BARMAR@POLYCARP.THINK.COM>
Date: Wed, 17 Jun 1987 14:49 EDT
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
In reply to: Barry Margolin <barmar at AQUINAS.THINK.COM>
There is also a big hole in STRICT-REDEFINITION as currently proposed.
This paragraph suggests that one might coerce a symbol or lambda list to
a function at runtime, but the proposal doesn't mention any new function
that one would call to do this. There needs to be a MAKE-FUNCTION
function, which takes a symbol or lambda list and returns the
corresponding function. It probably should have an optional environment
argument, too. It might be equivalent to
(defun make-function (thing &optional env)
(eval `(function ,thing) env))
However, it should probably be a primitive so that implimentations can
do it optimally.
We do NOT want to add an environment argument to MAKE-FUNCTION. APPLY
and FUNCALL currently interpret symbols and lambda expressions in the
null lexical environment, not the surrounding one. That must be the
case, since the symbol or lambda may have come from some very different
part of the program.
I now agree with this.
As for whether MAKE-FUNCTION should be added, I still think it should
be. If STRICT-REDEFINITION is adopted, then programmers who want to
turn lambda lists into functions will need a reasonable way to do this.
Yes, (EVAL `(FUNCTION ,LAMBDA-LIST)) will do it, but I don't think users
should have to write this. Generally, Lisp programmers are taught that
they should rarely need to invoke EVAL directly, unless they are
implementing an embedded language or something along those lines.
Consider the function:
(defun read-apply-print-loop ()
(loop (print (apply (make-function (read)))))
This isn't an embedded language, and there's no reason it should have to
call EVAL directly.
The coercion is so trivial that I figured anyone writing a package to
convert old code to run under the STRICT-REDEFINITION rules could figure
out how to do it with no problem. And since this is a temporary crutch
for use on onconverted old code, I certainly don't think that we want to
add anything like MAKE-FUNCTION to the language; for all new code, users
will invoke FUNCTION for themselves in the appropriate places.
I don't agree that this is a temporary crutch only for old code. There
is no way to write the above function without manually coercing lambda
lists to functions, because the lambda list that it is trying to apply
did not come from another program, it was generated on the fly (in this
case by the reader). There is no way for read to return a function
object (actually, there is a disgusting way, q.v.), it can only return a
lambda list.
Here's the disgusting way to make READ return a function: the user can
type "#.#'(lambda ...)".
barmar
∂17-Jun-87 1312 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Jun 87 13:12:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 175697; Wed 17-Jun-87 16:11:37 EDT
Date: Wed, 17 Jun 87 16:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: X3J13@SAIL.STANFORD.EDU
cc: CL-Cleanup@Sail.Stanford.Edu
In-Reply-To: <870616-155121-101@Xerox>
Message-ID: <870617161131.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Since apparently we're going to discuss this proposal at length on the
X3J13 mailing list, I just wanted to point out one minor hole in it.
CONVERSION COST:
One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
There is a large number of functions hiding inside that little "etc."
By my count there are 61 functions in Common Lisp that take :test or :key
arguments. There are probably a few other functions that call FUNCALL
or APPLY internally.
∂17-Jun-87 1535 DLW@ALDERAAN.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Jun 87 15:35:51 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 93095; Wed 17-Jun-87 18:15:56 EDT
Date: Wed, 17 Jun 87 18:15 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: IF-BODY (Version 7)
To: CL-CLEANUP@Sail.stanford.edu, X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
In-Reply-To: <870616-170738-108@Xerox>
Message-ID: <870617181519.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No
Date: 16 Jun 87 17:07 PDT
From: Masinter.pa@Xerox.COM
If this proposal is not accepted, it should be mandated that
extensions to IF are explicitly disallowed. The status quo, where there
is a tacit acceptance of extensions which are not portable and difficult
to detect, is unacceptable.
I'd like to state emphatically that I do not agree with this point of
view about extensions. The original point of Common Lisp was to be a
large common subset, designed to allow portable programs without
stifling extensions and experimentation, and without creating massive
compatibility problems. (I say "massive" because that's what would
happen if a policy of such explicit disallowal were applied across the
board.) If this attitude had prevailed at the beginning, there would
have been no Common Lisp.
I take the position that there ought to be tools that specifically help
you make sure that your program can be expected to run portably in other
CL implementations. The extended IF is not particularly "difficult to
detect" for such a tool; in fact, it's very easy. Meanwhile, the
extended implementation need not print out any warnings.
Such a portability tool is needed for other reasons: even if a
particular CL implementation doesn't have any "extensions", nevertheless
it necessarily makes choices about things that the CL manual leave up to
the implementation, and a program could be depending on those choices.
∂17-Jun-87 1740 Mike%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU updcoming meeting
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 17:40:16 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Jun 87 20:39-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 47846; 17 Jun 87 20:38:56-EDT
Date: Wed, 17 Jun 87 18:32 EDT
From: Mike%acorn@oak.lcs.mit.edu
Subject: updcoming meeting
To: x3j13@sail.stanford.edu
Message-ID: <870617183245.1.MIKE@ACORN.Gold-Hill.DialNet.Symbolics.COM>
Sorry if you received this twice.
To: x3j13 participants
From: Gold Hill Computers
163 Harvard St.
Cambridge, MA 02139
617-492-2071
Gold Hill is handling the arrangements for the meeting
on June 30 and July 1.
The MIT/AI Lab has graciously offered to provide space
for the meetings on the 8th floor at 545 Technology Square,
Cambridge MA. In addition, classroom space for sub-committee
meetings on June 29 is also being provided. Room numbers
are as follows: 512, 516, 204, and 773.
Arrangements with the Cambridge Marriott Hotel for rooms
at a special rate of $115 have been arranged.
Contact Dana at Gold Hill about these rooms.
Arrangements have also been made with Delta Airlines for a
special fare. This will be a 30% discount on "Selling Y"
fares. It can apply to either coach or special coach fares.
Reservations must be made at least seven days in advance.
To use this discount, call Delta at 1-800-641-6760.
The identifying file number is A1680. The identifying
name is X3J13.
There will be a charge of $40 for each participant for
catering services provided for breakfast pastry,
coffee and lunch for both days.
My apologies about the late notifications.
Dana Kawiecki
Coordinator.
P.S., we regret that due to network failures, there is no
reliable way to contact Gold Hill by electronic mail at the
present time.
∂17-Jun-87 2011 FAHLMAN@C.CS.CMU.EDU Issue: IF-BODY (Version 7)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 20:11:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 17 Jun 87 23:10:30-EDT
Date: Wed, 17 Jun 1987 23:10 EDT
Message-ID: <FAHLMAN.12311365480.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: X3J13@SAIL.STANFORD.EDU
Subject: Issue: IF-BODY (Version 7)
In-reply-to: Msg of 16 Jun 1987 20:07-EDT from Masinter.pa at Xerox.COM <CL-CLEANUP at Sail.stanford.edu>
Since I will not be able to atend the X3J13 in Boston, I would like to
state my views on this proposal via mail. This message may also help to
explain what the "disagreements within the cleanup committee" were all
about.
If we look at this proposed extension purely as a matter of language
design, I am opposed to it, but not violently so. I think that it is
confusing to see something like
(IF pred-clause
clause-1
clause-2
clause-3
and-so-on)
in a program. The then-clause gets lost in all the clutter, and it is
harder to understand the program in a quick scan. If there
must be multiple else-clauses, I prefer to see something like
(IF pred-clause
(PROGN then-clause-1
then-clause-2)
(PROGN else-clause-1
else-clause-2
and-so-on))
The two distinct conditional branches jump out at you in this case.
Since this extension would affect my ability to READ Common Lisp code,
it is little consolation that I don't have to use the new construct
myself.
Another problem with the proposed extension: If one is allowed only one
"then" clause but multiple "else" clauses, some users will be tempted to
negate the test in order to get the more complex result into the "else"
position. Again, this makes code harder to read and understand. It is
no big thing, but neither is an occasional PROGN.
Well, so much for my own sense of aesthetics. If the members of X3J13
disagree -- if they really feel that the proposed extension improves
Common Lisp -- then so be it.
The real disagreement concerned the other argument in the proposal. It
goes roughly like this: Some manufacturers have unilaterally adopted
this extension. Their users get screwed when they move their code into
Common Lisp systems without this extension. The extension is compatible
and relatively innocuous. Therefore, we should force every Common Lisp
to adopt this extension so that these poor users won't have to suffer.
Or, if we are unwilling to do that, we must explicitly outlaw this
extension. (Clever straw-man, that.)
I think that it would be a very dangerous precedent if we were to give
this argument any weight whatsoever. This same line of argument could
be used to smuggle all sorts of idiotic extensions into the language.
It has always been an important principle of Common Lisp that
implementation-specific extensions are allowed; we would never have
reached agreement if this were not the case. So it would be wrong to
outlaw the extended form of IF. But code that makes use of non-portable
extensions is not portable, and its users should not expect it to be.
Vendors of extended Common Lisp systems should make life easy for the
developers of portable code by providing a compiler mode that warns
about non-standard usage. In the case of extended IF, this would be
very easy, and the fix is equally easy: just add a PROGN. So if users
really are experiencing the portability problems described in this
proposal, they should ask the manufacturer of the system they are using
to provide such a tool. That is the right way to handle portability
problems caused by non-standard extensions. If the manufacturer doesn't
think the portability problem is serious enough to fix, why should we
change the language to make this system's users more comfortable?
It is not adequate to encourage implementors to warn about non-standard
uses since the only implementations which will implement the extension
are ones who think it is a good idea to use the feature, and people are
not inclined to warn about things they think are a good idea to use.
That's an amazingly arrogant position. It is quite possible to think
that a non-portable feature is wonderful and still provide your
customers with a "warn about non-portable usage" mode that will save
them from hassles if they ever need to move their code to some less
enlightened system that merely implements the Common Lisp standard.
Anyway, that's what the disagreement was about, along with much
procedural discussion about how much of this debate should appear in the
proposal and about whether the proposal should go out at all.
-- Scott
∂18-Jun-87 0736 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Jun 87 07:36:26 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 18 Jun 87 10:35:41-EDT
Date: Thu, 18 Jun 1987 10:35 EDT
Message-ID: <FAHLMAN.12311490219.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: X3J13@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
In-reply-to: Msg of 17 Jun 1987 16:11-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
In response to Moon:
I tried to respond to this yesterday, but it looks like the mail system
ate my message. My apologies if anyone sees this twice.
One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc...
There is a large number of functions hiding inside that little "etc."
By my count there are 61 functions in Common Lisp that take :test or :key
arguments. There are probably a few other functions that call FUNCALL
or APPLY internally.
This is true. However, it still is not particularly hard for a
code-walker or even a smart editor macro to find all of these :test and
:key arguments and to see if they need repair. In the overwhelming
majority of these cases, the functional argument is sitting there
explicitly after the keyword, either quoted or already wrapped in a
FUNCTION. The former can be fixed trivially, and the latter need no
fixing. Very few of these cases will end up requiring a runtime
type-test.
-- Scott
∂18-Jun-87 0821 shebs%orion@cs.utah.edu IF with multiple ELSE
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 18 Jun 87 08:21:26 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA00828; Thu, 18 Jun 87 09:23:09 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA12575; Thu, 18 Jun 87 09:23:06 MDT
Date: Thu, 18 Jun 87 09:23:06 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8706181523.AA12575@orion.utah.edu>
To: x3j13@sail.stanford.edu
Subject: IF with multiple ELSE
Count this as an absentee ballot against multiple ELSEs in IF. This
"feature" is in PSL, and it has been troublesome for maintainers on
several occasions. There doesn't seem to be any significant reasons
besides compatibility. In general, Common Lisp has been contorted by
the desire to retain compatibility - now that CL has proven successful
and the older dialects have faded somewhat, compatibility should take
a back seat to making the language more reasonable.
stan
∂18-Jun-87 0913 barmar@AQUINAS.THINK.COM Issue: IF-BODY (Version 7)
Received: from [192.5.104.1] by SAIL.STANFORD.EDU with TCP; 18 Jun 87 09:13:25 PDT
Received: from OCCAM.THINK.COM by AQUINAS.THINK.COM via CHAOS with CHAOS-MAIL id 33136; Thu 18-Jun-87 12:16:18 EDT
Date: Thu, 18 Jun 87 11:27 EDT
From: Barry Margolin <barmar@AQUINAS.THINK.COM>
Subject: Issue: IF-BODY (Version 7)
To: Scott E. Fahlman <Fahlman@c.cs.cmu.edu>
cc: X3J13@sail.stanford.edu
In-Reply-To: <FAHLMAN.12311365480.BABYL@C.CS.CMU.EDU>
Message-ID: <870618112702.1.BARMAR@OCCAM.THINK.COM>
Date: Wed, 17 Jun 1987 23:10 EDT
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
If we look at this proposed extension purely as a matter of language
design, I am opposed to it, but not violently so.
I'm not going to discuss the esthetics of the change, but I agree with
Scott that we shouldn't change IF (even though I occasionally use
multiple else-clauses in my own programs, but most of them make
extensive use of Symbolics OS features already, so they are not
portable).
It is not adequate to encourage implementors to warn about non-standard
uses since the only implementations which will implement the extension
are ones who think it is a good idea to use the feature, and people are
not inclined to warn about things they think are a good idea to use.
That's an amazingly arrogant position. It is quite possible to think
that a non-portable feature is wonderful and still provide your
customers with a "warn about non-portable usage" mode that will save
them from hassles if they ever need to move their code to some less
enlightened system that merely implements the Common Lisp standard.
There's been quite a bit of discussion about how to deal with extensions
before, and I'm going to restate my opinion.
It seems to me that it should not be that difficult to provide such a
facility, simply by using the package system. The Common Lisp
implementation I'm most familiar with is Symbolics, and they provide
their own package, SYMBOLICS-COMMON-LISP, which imports everything in
LISP and exports them plus all the Symbolics extensions. What they
could do is shadow in SCL any functions/special forms that are extended,
i.e.
(SI:DEFINE-SPECIAL-FORM LISP:IF
IF-EXPANDER (PRED THEN ELSE)
...)
(SI:DEFINE-SPECIAL-FORM SCL:IF
IF-EXPANDER (PRED THEN &REST ELSES)
...)
Portable applications would normally be written in packages that :USE
LISP, while non-portable applications could :USE SCL.
I realize that the package scheme doesn't solve all problems with
extensions, but it can go a long way. It could be used to solve this
problem, as well as LOOP (unless and until the fancy LOOP macro is
adopted).
barmar
∂18-Jun-87 1001 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 Jun 87 10:01:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 176524; Thu 18-Jun-87 12:59:36 EDT
Date: Thu, 18 Jun 87 12:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: X3J13@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12311490219.BABYL@C.CS.CMU.EDU>
Message-ID: <870618125936.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 18 Jun 1987 10:35 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
In response to Moon:
One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc...
There is a large number of functions hiding inside that little "etc."
By my count there are 61 functions in Common Lisp that take :test or :key
arguments. There are probably a few other functions that call FUNCALL
or APPLY internally.
This is true. However, it still is not particularly hard for a
code-walker or even a smart editor macro to find all of these :test and
:key arguments and to see if they need repair. In the overwhelming
majority of these cases, the functional argument is sitting there
explicitly after the keyword, either quoted or already wrapped in a
FUNCTION. The former can be fixed trivially, and the latter need no
fixing. Very few of these cases will end up requiring a runtime
type-test.
Scott, the "automatic strategy" sentence that I quoted out of context
was in the context of discussing how to put in run-time type tests.
∂18-Jun-87 1740 RWK@YUKON.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 18 Jun 87 17:40:51 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 226953; Thu 18-Jun-87 20:24:59 EDT
Date: Thu, 18 Jun 87 20:24 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Issue: IF-BODY (Version 7)
To: Barry Margolin <barmar@AQUINAS.THINK.COM>
cc: Scott E. Fahlman <Fahlman@c.cs.cmu.edu>, X3J13@sail.stanford.edu
In-Reply-To: <870618112702.1.BARMAR@OCCAM.THINK.COM>
Message-ID: <870618202441.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 18 Jun 87 11:27 EDT
From: Barry Margolin <barmar@AQUINAS.THINK.COM>
It seems to me that it should not be that difficult to provide such a
facility, simply by using the package system. The Common Lisp
implementation I'm most familiar with is Symbolics, and they provide
their own package, SYMBOLICS-COMMON-LISP, which imports everything in
LISP and exports them plus all the Symbolics extensions. What they
could do is shadow in SCL any functions/special forms that are extended,
i.e.
This doesn't work so well if there are any applications or any part of
CL that uses that symbol for EQness. For example, if I ran an application
that used 'IF as part of the protocol for interfacing to it, and it was
written in strict CL (and was therefor loaded into our LISP: package)
and I wanted to use it from SCL, things would start getting very confusing.
If you're just dealing with a single application, however, this works so
long as the symbol isn't one of the few symbols that CL uses the EQness
of (such as DOCUMENTATION, VARIABLE, EVAL, COMPILE, LOAD, EQ, EQL, EQUAL,
&ALLOW-OTHER-KEYS, &AUX, &BODY, &ENVIRONMENT, &KEY, &OPTIONAL, &REST, or
&WHOLE.
You also screw up importing any "portable" program-understanding code
that knows anything about that symbol. (Program-understanding code
is not necessarily some big thing that knows the whole language; SETF
is a much smaller example).
In general, shadowing has a lot to disrecommend it as a strategy for
extending Common Lisp.
These comments don't apply, however, to sub-environments intended
directly for developing and testing code intended to be strictly
portable.
∂18-Jun-87 2350 RWK@YUKON.SCRC.Symbolics.COM IF with multiple ELSE
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 18 Jun 87 23:50:14 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 227051; Fri 19-Jun-87 02:49:51 EDT
Date: Fri, 19 Jun 87 02:49 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: IF with multiple ELSE
To: Stanley T. Shebs <shebs%orion@cs.utah.edu>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8706181523.AA12575@orion.utah.edu>
Message-ID: <870619024952.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 18 Jun 87 09:23:06 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Count this as an absentee ballot against multiple ELSEs in IF. This
"feature" is in PSL, and it has been troublesome for maintainers on
several occasions. There doesn't seem to be any significant reasons
besides compatibility. In general, Common Lisp has been contorted by
the desire to retain compatibility - now that CL has proven successful
and the older dialects have faded somewhat, compatibility should take
a back seat to making the language more reasonable.
stan
On the contrary! This is not an issue of compatibility with
older dialects. There are two reasons:
1) Convenience. Several modern dialects have it because we find it
very convenient to use.
1a) Inconvenience of the alternative. PROGN hastens your indentation's
march to the right edge of your screen.
2) Compatibility with those *modern* dialects which choose to extend
IF in this way.
The issue isn't compatibility with older dialects; I agree that can take
a back seat.
While I'm at it, I may as well point out that many of us who use the
extended IF indent it in a way that the THEN and ELSE clauses are
readily distinguished. I find
(IF (CONDITION-FORM)
(THEN-FORM)
(ELSE-FORM))
confusing, even without additional ELSE forms, especially if the
condition form is longer than one line. I prefer
(IF (CONDITION-FORM)
(THEN-FORM)
(ELSE-FORM))
I think this would render the "readability" argument irrelevant,
except there are those who dislike this for reasons I've never
fathomed. (But let's not debate what the best indentation is
here, please! I'm just pointing out the alternative).
∂19-Jun-87 2100 edsel!bhopal!jonl@navajo.stanford.edu IF with multiple ELSE
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Jun 87 21:00:21 PDT
Received: by navajo.stanford.edu; Fri, 19 Jun 87 20:57:39 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05237; Fri, 19 Jun 87 20:35:00 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA05585; Fri, 19 Jun 87 20:37:23 PDT
Date: Fri, 19 Jun 87 20:37:23 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706200337.AA05585@bhopal.edsel.uucp>
To: navajo!RWK%YUKON.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!shebs%orion%cs.utah.edu@navajo.stanford.edu,
navajo!x3j13%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: Robert W. Kerns's message of Fri, 19 Jun 87 02:49 EDT <870619024952.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Subject: IF with multiple ELSE
This may be a hopeless quest but . . .
Why is there so little interest in having a conditional form for CL that
more closely approximates the standard computer-science language conditionals
(for "standard .. languages", read "Algol-like").
Interlisp has a format that many use and love:
(if <condition1>
then <clause11> <clause12> ... <clause1n1>
elseif <condition2>
then <clause21> <clause22> ... <clause2n2>
. . .
else <clausem1> <clausem2> ... <clausemnm>
)
and I think Franz Lisp added this format in an essentially upward-compatible
way. The only flaw with such an extension is that the word THEN can't be
used as an ordinary then clause by itself [but then again, how many times
does "then" or "else" appear as local variables, in programs like
(if <mumble> then 5)
where the ambiguity is apparent].
Isn't Common Lisp really much less than "modern" by providing only the
crude form (if <form1>
<form2>
<form3>)
as the primary conditional paradigm?
-- JonL --
∂19-Jun-87 2204 Moon@STONY-BROOK.SCRC.Symbolics.COM IF with multiple ELSE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Jun 87 22:04:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 177997; Sat 20-Jun-87 01:02:55 EDT
Date: Sat, 20 Jun 87 01:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IF with multiple ELSE
To: Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8706200337.AA05585@bhopal.edsel.uucp>
Message-ID: <870620010248.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Use COND.
If you don't like the parentheses, use M-expressions.
∂20-Jun-87 0437 edsel!bhopal!jonl@navajo.stanford.edu IF with multiple ELSE
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jun 87 04:37:26 PDT
Received: by navajo.stanford.edu; Sat, 20 Jun 87 04:34:48 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05823; Sat, 20 Jun 87 03:24:42 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA05994; Sat, 20 Jun 87 03:27:06 PDT
Date: Sat, 20 Jun 87 03:27:06 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706201027.AA05994@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!x3j13%sail@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 20 Jun 87 01:02 EDT <870620010248.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: IF with multiple ELSE
Re: Use COND.
If you don't like the parentheses, use M-expressions.
Is this a reply to the query "Why is Common Lisp aping ALGOL, but
winding up blatantly idiosyncratic, and for no useful reason"? If
so, then it it may well be interpreted as
Use FORTRAN (has 1950's level syntax, just like COND)
If you don't like the 80-column lines, use PascaModulADAlgolC
-- JonL --
∂21-Jun-87 1652 franz!frisky!jkf@ucbarpa.Berkeley.EDU Re: IF with multiple ELSE
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 21 Jun 87 16:51:00 PDT
Received: by ucbarpa.Berkeley.EDU (5.57/1.25)
id AA07095; Fri, 19 Jun 87 23:30:13 PDT
Received: from frisky by franz (5.5/3.14)
id AA29568; Fri, 19 Jun 87 23:20:19 PDT
Received: by frisky (3.2/3.14)
id AA13854; Fri, 19 Jun 87 23:15:50 PDT
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8706200615.AA13854@frisky>
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>,
x3j13@sail.stanford.edu
Subject: Re: IF with multiple ELSE
In-Reply-To: Your message of Sat, 20 Jun 87 01:02:00 EDT.
<870620010248.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 19 Jun 87 23:15:49 PDT
>> Use COND.
Did you forget the little smiley face?
I've got a lot of experience using a if form with 'then', 'elseif' and
'else' clauses and I'd rate it about an order of magnitude more
readable than cond. I'd also rate 'cond' about a half order of
magnitude more readable than the common lisp 'if' (which is downright
unreadable).
∂22-Jun-87 0935 DLW@ALDERAAN.SCRC.Symbolics.COM Re: IF with multiple ELSE
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 22 Jun 87 09:35:52 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 94385; Mon 22-Jun-87 12:03:15 EDT
Date: Mon, 22 Jun 87 12:02 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: IF with multiple ELSE
To: franz!frisky!jkf@ucbarpa.Berkeley.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: edsel!bhopal!jonl@navajo.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: <8706200615.AA13854@frisky>
Message-ID: <870622120219.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
It seems clear that this is one of those "matter of taste" issues,
depending a lot on personal preference and what you're accustomed to.
My experience has been that electronic mail discussions are not very
useful for such issues. Perhaps normal X3J13 channels would be more
effective.
∂22-Jun-87 1013 cperdue@Sun.COM Re: IF with multiple ELSE
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 10:13:04 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2)
id AA02476; Mon, 22 Jun 87 10:09:34 PDT
Received: from clam.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA07547; Mon, 22 Jun 87 10:08:51 PDT
Received: by clam.sun.com (3.2/SMI-3.2)
id AA05089; Mon, 22 Jun 87 10:12:52 PDT
Date: Mon, 22 Jun 87 10:12:52 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8706221712.AA05089@clam.sun.com>
To: DLW@ALDERAAN.SCRC.Symbolics.COM
Subject: Re: IF with multiple ELSE
Cc: x3j13@sail.stanford.edu
It seems clear that this is one of those "matter of taste" issues,
depending a lot on personal preference and what you're accustomed to.
My experience has been that electronic mail discussions are not very
useful for such issues. Perhaps normal X3J13 channels would be more
effective.
This is more than a "matter of taste" issue. It is also a readability,
clarity, and error-proneness issue. My thanks are to JonL for bringing
this up. My personal vote has been for if with "then" and "else"
keywords and multiple "else" clauses ever since I first began to
use Interlisp-10 several years ago.
If-then-else-etc. in fact is a well-established part of my personal Lisp
programming practice. Let's pursue this issue further.
∂22-Jun-87 1112 DLW@ALDERAAN.SCRC.Symbolics.COM Re: IF with multiple ELSE
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 22 Jun 87 11:12:22 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 94440; Mon 22-Jun-87 14:12:04 EDT
Date: Mon, 22 Jun 87 14:11 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: IF with multiple ELSE
To: cperdue@Sun.COM
cc: x3j13@sail.stanford.edu
In-Reply-To: <8706221712.AA05089@clam.sun.com>
Message-ID: <870622141115.8.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 22 Jun 87 10:12:52 PDT
From: cperdue@Sun.COM (Cris Perdue)
Let's pursue this issue further.
The only point I was trying to make is that I don't think that it will
be valuable to continue to discuss this over the X3J13 mailing list.
∂22-Jun-87 1126 FAHLMAN@C.CS.CMU.EDU IF with multiple ELSE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Jun 87 11:23:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 22 Jun 87 14:12:18-EDT
Date: Mon, 22 Jun 1987 14:12 EDT
Message-ID: <FAHLMAN.12312578230.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: x3j13@SAIL.STANFORD.EDU
Subject: IF with multiple ELSE
In-reply-to: Msg of 22 Jun 1987 13:12-EDT from cperdue at Sun.COM (Cris Perdue)
Regarding the (if ... then ... else ...) proposal:
This is the same rock on which every attempt to come up with a LOOP-like
construct has run aground: some people like the Interlisp/MIT-Loop-macro
style in which you have lengthy flat lists punctuated with reserved
symbols that play a syntactic role; others hate this and prefer a
"Lispy" syntax in which nested list structure is used to organize the
clauses and parts of a clause. I suppose that if we decide to swallow
the "psuedo-English" syntax for LOOP, then (if ... then ... else
...) is a natural thing to add as well. I suppose that one of these
days we will have to come to grips with this whole bag of worms again --
isn't there a committee working on this?
The current form of IF looks just fine to me, but that is probably a
matter of having seen so many of them. I once saw some code by Joe
Ginder (don't know if the idea was original with him or not) that simply
defined THEN and ELSE as macros that expand into PROGN of the same body.
Once can then write
(if <predicate>
(then clause
clause ...)
(else clause
clause ...))
A perverse programmer could really confuse things by switching the THEN
and ELSE symbols, but perverse programmers can write obscure code in any
event.
-- Scott
∂22-Jun-87 1207 barmar@Think.COM Re: IF with multiple ELSE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 12:07:29 PDT
Received: from occam by Think.COM via CHAOS; Mon, 22 Jun 87 15:07:19 EDT
Date: Mon, 22 Jun 87 15:04 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: IF with multiple ELSE
To: Cris Perdue <cperdue@sun.com>
Cc: DLW@alderaan.scrc.symbolics.com, x3j13@sail.stanford.edu
In-Reply-To: <8706221712.AA05089@clam.sun.com>
Message-Id: <870622150454.2.BARMAR@OCCAM.THINK.COM>
Date: Mon, 22 Jun 87 10:12:52 PDT
From: cperdue@sun.com (Cris Perdue)
It seems clear that this is one of those "matter of taste" issues,
depending a lot on personal preference and what you're accustomed to.
My experience has been that electronic mail discussions are not very
useful for such issues. Perhaps normal X3J13 channels would be more
effective.
This is more than a "matter of taste" issue. It is also a readability,
clarity, and error-proneness issue. My thanks are to JonL for bringing
this up. My personal vote has been for if with "then" and "else"
keywords and multiple "else" clauses ever since I first began to
use Interlisp-10 several years ago.
If-then-else-etc. in fact is a well-established part of my personal Lisp
programming practice. Let's pursue this issue further.
Unless someone plans on doing some human factors experiments, we will
not be able to make any objective decision about the "readability,
clarity, and error-proneness issue". The matter of taste that Dan
referred to was the fact that different people find the different forms
more readable, clear, or error-prone. Without concrete data, taste is
all we can go by. What we've seen so far is lots of people saying,
"well, I've been using FOO-LISP's WHIZ-BANG-IF feature for years, and
it's really great." Lots of people swore by Interlisp's DWIM feature,
but it wasn't put into CL either.
barmar
∂22-Jun-87 1214 shebs@cs.utah.edu Purpose of this Mailing List
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 22 Jun 87 12:10:43 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA09296; Mon, 22 Jun 87 13:12:32 MDT
Date: Mon, 22 Jun 87 13:12:32 MDT
From: shebs@cs.utah.edu (Stanley Shebs)
Message-Id: <8706221912.AA09296@cs.utah.edu>
To: x3j13@sail.stanford.edu
Subject: Purpose of this Mailing List
What exactly is this mailing list for? It's pretty clear that arguments
will be carried on anywhere that they are not specifically forbidden.
To reduce traffic, this list should be one-way from committees to everybody
else, with all replies going to committees again, or else each individual
is allowed one public response to any single proposal from a committee.
stan
∂23-Jun-87 1104 RPG Meeting Room at MIT
To: x3j13@SAIL.STANFORD.EDU
Several people have pointed out to me that the 8th floor of 545 Tech
Square must be the AI Lab playroom. I had not really thought about where
the meeting might be held, and when I investigated further, I found out it
was indeed the playroom. The playroom, though colorful, is not an appropriate
place to meet because it is surrounded by the open doors of offices.
The person at Gold Hill who made the arrangements is out of town this
week, so I asked Rod Brooks to look into the situation. He found out that
the playroom was booked for Monday and Tuesday of next week. He reserved
6-120 (Building 6, room 120), which seats 175, for Tuesday and Wednesday
of next week for us. This room is in the eastern leg of the large
U-shaped building with the dome at the bottom and whose open end faces the
Charles river.
Since it might be that the current arrangements are for the wrong two days,
the catering plans might need to be altered, but I am unable to do that
until I can reach someone at Gold Hill.
I am leaving for Boston Friday morning, and, unless I can provide more
information before I leave, you ought to visit the playroom on the
8th floor when you arrive to find out where the meeting will really
be held.
-rpg-
∂25-Jun-87 2342 RPG Meeting Room
To: x3j13@SAIL.STANFORD.EDU
As of today it appears that the meeting room will be 6-120 at MIT. There
will be a sign at each room stating which room is the correct one.
-rpg-
∂26-Jun-87 1048 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Meeting Room
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 26 Jun 87 10:48:07 PDT
Received: from HAL.CAD.MCC.COM by MCC.COM with TCP; Fri 26 Jun 87 12:46:34-CDT
Date: Fri, 26 Jun 87 12:46 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Meeting Room
To: x3j13%SAIL.STANFORD.EDU@MCC.COM
cc: Loeffler@MCC.COM
In-Reply-To: <8706260705.AA01887@bell>
Message-ID: <870626124601.5.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
Date: 25 Jun 87 2342 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
As of today it appears that the meeting room will be 6-120 at MIT. There
will be a sign at each room stating which room is the correct one.
-rpg-
Would someone please see that maps are provided at the hotel for those
that do not know how to navigate the MIT campus.
-- David D. Loeffler
∂30-Jun-87 1109 procyon@Cs.Ucl.AC.UK Common Lisp Mailing List
Received: from [14.0.0.9] by SAIL.STANFORD.EDU with TCP; 30 Jun 87 11:08:22 PDT
Date: Tue, 30 Jun 87 18:55:53 BST
From: Richard Barber (ProcyonResearch) <procyon@Cs.Ucl.AC.UK>
To: x3j13@sail.stanford.edu
cc: mathis@c.isi.edu
Subject: Common Lisp Mailing List
We now have an ARPANET address. Please can you add us to the X3J13 mailing
list.
We haven't had any mailings from the committee for quite a while now. Perhaps
you haven't received our subscription?
Richard Barber
Procyon Research Limited
England.
∂02-Jul-87 1648 MATHIS@ADA20.ISI.EDU BALLOT! ISO NWI
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 2 Jul 87 16:48:48 PDT
Date: 2 Jul 1987 06:14-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: BALLOT! ISO NWI
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 2-Jul-87 06:14:29.MATHIS>
This is to inform/remind all of you that there will be a mail
ballot on the ISO New Work Item on Lisp. This was distributed
and discussed at the recent meeting in Cambridge. There will be
a very short respose time. Expect to see something on the net
this weekend and in your physical mail next week. -- Bob
∂05-Jul-87 1803 MATHIS@ADA20.ISI.EDU DRAFT letter and ballot
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jul 87 18:03:19 PDT
Date: 5 Jul 1987 18:02-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: DRAFT letter and ballot
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jul-87 18:02:46.MATHIS>
What follows is a DRAFT of my letter and the X3J13 ballot
on the ISO New Work Item. This is not! the final version.
It is being sent to you for comment and advance notice.
Please comment within two days. -- Bob
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 1
Doc. No.: X3J13/87-030
Date: 87-07-06
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
(703)425-5923
Mathisda20.isi.edu
X3J13 Members and Mailing List Observers:
ACTION REQUIRED -- This mailing includes a mail ballot which must
______ ________
ACTION REQUIRED
______ ________
be returned by active US members of X3J
DEADLINE: NOON, July 28, 1987
________
DEADLINE
________
Copies of this ballot are being sent to all people on the X3J13
mailing list in a spirit of open communication and cooperation.
You are all welcome to send me comments on this issue, but you
should indicate what you want me to do with them; for example,
forward them to X3, forward them to the rest of X3J13, o
them to myself.
At the recent meeting of X3J13, the ISO "Proposed NWI [New Work
Item] on Programming Language Lisp (TC97 N 19206-092)
(X3J13/87-024) (also included with this mailing) was distributed
and discussed. It was decided that at least parts of this issue
had to have a written ballot and thus the whole issue should be
the subject of a mail ballot of X3J13.
The following are my summaries of the issues involved and the
discussions we had at the recent meeting. In being a summary it
means that some details have to be left out. I have tried to be
objective and put the issues clearly, but there may yet be some
other things that people ant to say. Our electronic mailing list
(X3J13s available for discussion. Anything
you put there which you want included with the record of this
vote should be forwarded to me with appropriate indications of
your wishes. Anyone who has a comment they would like put on the
electronic mailing list, but who does not have access to do it
himself, can send it to me in hard copy form and I will
redistribute it electronically.
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 2
I must have our response to X3 by July 29, 1987. I intend to take
it to them personnally that day. To be able to do that, I need to
have your responses by noon on Tuesday, July 28. If you are
intending to send in comments along with your ballot, I would
like to know that earlier if possible.
When the formation of an X3 technical subcommittee on Common Lisp
was first proposed, the documents also included a new work item
(NWI) proposal for ISO work in this same area. Both were passed
by X3 at that time. That NWI passed through TC97 to an ad hoc
group within SC22 which had been set up to consider NWIs in this
area. This NWI which we are now considering (TC97 N 1929) is a
revised version of that same NWI which was previously approved by
X3.
X3J13 has spent considerable time discussing its own goals, plan
of work and purposes and summarized its position in X3J13/SD-05
(discussed at the first two meetings and formally approved at the
third, March 16, 1987), which included "X3J13 is committed to
work with ISO toward an international Lisp standard."
These actions clearly indicate that X3 and X3J13 are in favor of
ISO work in the Lisp area. There is however another question on
the TC97 ballot which raised some concerns, "Q.1 Do you accept
the proposal in document [ISO/TC97 N 1929] as a sufficient
definition of the new work item?"
As always when there are significant issues raised in discussing
a formal vote, it also has to be decided whether those concerns
are more appropriately conveyed privately to other people
involved with the project, attached to a yes vote, or as the
comments associated with a negative vote. Even though X3J13 is
basically in favor of ISO work in the Lisp area, once it was
decided to have a mail ballot on the other issue, it was also
necessary to include this fundamental question.
In the report of that ad hoc working group within TC97/SC22
(ISO/TC97/SC22 N 266) (the Lisp related portion of which was
redistributed as X3J13/86-017 and is enclosed again with this
letter), a number of issues were discussed. That report provides
the background for this NWI. In particular, the following
paragraph was included:
The name of the working group has also been a discussion
topic. Lisp is a generic name describing a family of
languages. As such it is not an appropriate name for an ISO
standard. The US has suggested Common Lisp since they
believe it will emerge as Level 2 in the ISO work. The
European group has been using the name EuLisp for their
work. In approving a NWI in this area, the resulting working
group should be tasked to resolve this name issue. For
example, if Level 2 does turn out to be Common Lisp, that is
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 3
a well recognized name by which it should be called; on the
other hand, to call it that at the beginning would prejudge
the work in a way which is at the moment unacceptable.
Although the NWI does not say so explicitly, it should be assumed
that a new working group will start its work from the place where
that ad hoc working group left off, so it should not be necessary
to remind them formally of the content of that report.
If comments are to accompany the US response, the following
paragraph is being suggested. It is written so as to go with
either a positive or negative vote on whether the description of
the NWI is sufficient or not. This paragraph was not reviewed at
the meeting, but has been informally reviewed with some of the
members to be sure that it represents the views that were
expressed at the meeting and serves as an appropriate choice in
the context of this ballot.
Proposed Comments
________ ________
In the US there is a very strong feeling that "Lisp" is the
name of a family of languages and that it is appropriate to
standardize only on a particular dialect and that the name
of this dialect must be part of the name of the standard. A
name like "ISO Lisp 89" would be too broad and would not
answer the concerns expressed here. Within the Lisp family,
there have existed many popular dialects with fundamental
differences in their design, implementation, and use. While
some of these existing differences may be resolved, others
will certainly appear since the Lisp family encourages such
experimentation and development.
The US concern about the name for the resulting ISO standard
and the wording of this proposed new work item is not a
shallow comment about words only, but is an indication of
our deep concern that the goals and objectives of developing
a standard within the Lisp family should not interfer with
continued developments in other parts of the Lisp family of
languages. This is one of the first issues that must be
considered by an ISO working group resulting from the
approval of this new work item. This naming issue was also
raised as part of the report of the SC22 ad hoc working
group (ISO/TC97/SC22 N 266) that lead to this NWI proposal.
The US feels that report should be one of the initial
documents of the working group resulting from this NWI
proposal and that the various issues it raises be addressed.
Some people felt that these concerns and opions were well known
and accepted within the Lisp community; and that it was always
the case that a standards working group had to spend some of its
initial time agreeing on specifics of purposes and objectives; so
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 4
it was not necessary to formally state these issues in the US
reponse to TC97. "If 'it goes without saying,' it goes without
saying." On the other hand there is the view that it is just such
"obvious" things that need to be put down for the record so that
the work can proceed. As the discussion went on, comments
intended to support not making any formal comments were returned
as "exactly the reasons we should comment," and vice versa.
This is the central issue that motivated this mail ballot and is
Question 3 on the enclosed ballot -- should these concerns be
__________
made a formal part of the US response or not. The other questions
are asked because of asking this one. You may of course have
other concerns and comments about this or other issues related to
this NWI, which you should include with your response.
The comments and discussion here (and any you formally send me)
will be seen by X3 members and their vote will determine what and
whether any comments will be forwarded to TC97 as part of the US
ballot. This letter is being sent to everyone on the X3J13
mailing list which includes many people who are likely to be on
the ISO working group; so these comments and concerns are being
made known. The issue is primarily whether or not they will be
made a part of the formal and official US response to ISO/TC97.
Besides summarizing the issues and the discussion, I also want to
give you an indication of the way I think the people at the
meeting felt. The questions were not put to them in exactly the
way they are here, not everyone at the meeting will be able to
vote in this mail ballot, not everyone entitled to vote was at
the meeting, and some people have probably changed their mind
since they last expressed their opinion to me; but I think most
of the people would have voted on the questions here in one of
the following three ways, with the first one listed being the
most popular and the last one the least popular, but with none of
them having a majority.
1. yes 2. yes 3. no
1. yes 2. yes 3. yes
1. yes 2. no 3. yes
(If you notice the Gray code nature of the above, you may also
have some insight into why this was not decideable at the meeting
and is being submitted to a mail ballot.)
Comments are required with "No" votes. Since I have tried to give
the reasons for voting either direction, I assume some of you
will make your decision for basically the reasons described here,
so I have split the "No" choice into two parts for Questions 2
and 3 -- the first being "No" for the reasons given in this
letter and the second being "No" for other/additional reasons (in
which case you must give them).
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 5
As to the other items on the ballot (Q.3 -- Q.7) the answers are
all "YES." [Q.3] The US is prepared to actively participate in
this work. [Q.4] We already have at least six people who are
members of X3J13 who are interested in serving on an ISO working
group. They have the technical background and the resources to
make effective contributions. Their participation in this new
working group would not detract from any existing TC97 related
work. [Q.5] The book Common Lisp: The Language by Guy L. Steele
_________________________
Jr. is already listed as a reference on the NWI proposal. X3J13
has also been working on proposals for an object system, an
errors and conditions system, interfaces with window systems,
iteration mechanisms, conformance and validation, various issues
related to the Steele book, the Lisp1/Lisp2 issue, and many
others. [Q.6] These and other US documents will be made available
to the ISO Working Group as soon as it is formed and continually
in the future. [Q.7] Richard Gabriel and William Clinger have
expressed their willingness and are arranging the support
necessary for them to take on the role of project editor for this
work. They are both well known in the Lisp community and
respected for their insight into Lisp issues and their writing
abilities.
It is the desire and intention of X3J13 to be as open and
communicative as possible with the ISO work. X3J13 will continue
to be very active in working toward a standard that serves the
needs of the US and Common Lisp communities. Relevant documents
(from whatever source) will be circulated to both X3J13 and the
ISO working group.
Remember that this letter, a copy of the ballot, a summary of the
voting, and any comments you submit will be forwarded as a
package to X3 for their consideration (and to the X3J13 mailing
list as well of course). Even though I have tried to be objective
in these summaries, some of you may want to comment on any part
of my letter, the ballot issues, or the position X3 should take.
Such comments are part of the public standards process. I also
want to remind you that you may want to directly contact the X3
member from your company or organization.
If you have any questions about your responsibilities and/or
rights related to this ballot or if any of the issues are still
unclear, please contact me at Mathisda20.isi.edu or (703)425-
5923.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 6
X3J13 Ballot on
Proposed NWI on Programming Language LISP (TC97 N 1929)
Deadline: Noon July 28, 1987 to Bob Mathis
_________
Question 1: X3J13 recommends to X3 a "YES" vote on the "Proposed
__________
NWI on Programming Language LISP (TC97 N 1929)"
YES NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
Question 2: X3J13 recommends to X3 a "YES" vote that the proposal
__________
in TC97 N 1929 is a sufficient definition of the new work item.
YES NO (for the reasons stated in X3J13/87-030's summary
of the issues and discussions)
NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
Question 3: X3J13 recommends that the "Proposed Comments" on page
__________
3 of X3J13/87-030 be attached as formal comments with the US
response to ISO/TC97 on this Proposed NWI. (An X3 vote of "NO" to
the sufficiency of definition will require that comments be
provided to TC97, but you may suggest ones other than those in
X3J13/87-030.)
YES NO (because YES votes on the previous two questions
will need no comments)
NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
There are some transmission errors in the above text; but I hope
it shows the main essence of the topic. -- Bob
∂12-Jul-87 2020 MATHIS@ADA20.ISI.EDU x3j13 ballot
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 12 Jul 87 20:19:37 PDT
Date: 12 Jul 1987 20:19-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: x3j13 ballot
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]12-Jul-87 20:19:06.MATHIS>
Doc. No.: X3J13/87-030
Date: 87-07-12
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
(703)425-5923
Mathis@Ada20.isi.edu
X3J13 Members and Mailing List Observers:
IMMEDIATE ACTION REQUIRED -- This mailing includes a mail ballot
which must be returned by active US members of X3J13.
DEADLINE: NOON, July 28, 1987 ELECTRONIC RESPONSE POSSIBLE (p. 4)
Copies of this ballot are being sent to all people on the X3J13
mailing list in a spirit of open communication and cooperation.
You are all welcome to send me comments on this issue, but you
should indicate what you want me to do with them; for example,
forward them to X3, forward them to the rest of X3J13, or keep
them to myself. Since the issue relates to the US position on an
ISO ballot, the US principal members of X3J13 are the ones who
must vote and who will determine the result.
At the recent meeting of X3J13, the ISO "Proposed NWI [New Work
Item] on Programming Language Lisp (TC97 N 1929)" (X3/87-06-092)
(X3J13/87-024) (also included with this mailing) was distributed
and discussed. It was decided that at least parts of this issue
had to have a written ballot and thus the whole issue should be
the subject of a mail ballot of X3J13. A draft of this letter and
ballot was distributed electronically for preliminary comment on
July 5, 1987.
The following are my summaries of the issues involved and the
discussions we had at the recent meeting. Being a summary it
means that some details have to be left out. I have tried to be
objective and put the issues clearly, but there may yet be some
other things that people want to say. Our electronic mailing list
(X3J13@SAIL. Stanford.edu) is available for discussion. Anything
you put there which you want included with the record of this
vote should be forwarded to me with appropriate indications of
your wishes. Anyone who has a comment they would like put on the
electronic mailing list, but who does not have access to do it
himself, can send it to me in hard copy form and I will
redistribute it electronically.
I must have our response to X3 by July 29, 1987. I intend to take
it to them personally that day. To be able to do that, I need to
have your responses by noon on Tuesday, July 28. If you are
intending to send in comments along with your ballot, I would
like to know that earlier if possible.
When the formation of an X3 technical subcommittee on Common Lisp
was first proposed, the documents also included a new work item
(NWI) proposal for ISO work in this same area. Both were passed
by X3 at that time. That NWI passed through TC97 to an ad hoc
group within SC22 which had been set up to consider NWIs in this
area. This NWI which we are now considering (TC97 N 1929) is a
revised version of that same NWI which X3 previously approved.
X3J13 has spent considerable time discussing its own goals, plan
of work and purposes and summarized its position in X3J13/SD-05
(discussed at the first two meetings and formally approved at the
third, March 16, 1987), which included "X3J13 is committed to
work with ISO toward an international Lisp standard."
These actions clearly indicate that X3 and X3J13 are in favor of
ISO work in the Lisp area. There is however another question on
the TC97 ballot which raised some concerns, "Q.1 Do you accept
the proposal in document [ISO/TC97 N 1929] as a sufficient
definition of the new work item?"
As always when there are significant issues raised in discussing
a formal vote, it also has to be decided whether those concerns
are more appropriately conveyed privately to other people
involved with the project, attached to a yes vote, or as the
comments associated with a negative vote. Even though X3J13 is
basically in favor of ISO work in the Lisp area, once it was
decided to have a mail ballot on the other issue, it was also
necessary to include this fundamental question.
In the report of that ad hoc working group within TC97/SC22
(ISO/TC97/SC22 N 266) (the Lisp related portion of which was
redistributed as X3J13/86-017 and is enclosed again with this
letter), a number of issues were discussed. That report provides
the background for this NWI. In particular, the following
paragraph was included:
The name of the working group has also been a discussion
topic. Lisp is a generic name describing a family of
languages. As such it is not an appropriate name for an ISO
standard. The US has suggested Common Lisp since they
believe it will emerge as Level 2 in the ISO work. The
European group has been using the name EuLisp for their
work. In approving a NWI in this area, the resulting working
group should be tasked to resolve this name issue. For
example, if Level 2 does turn out to be Common Lisp, that is
a well recognized name by which it should be called; on the
other hand, to call it that at the beginning would prejudge
the work in a way which is at the moment unacceptable.
Although the NWI does not say so explicitly, it should be assumed
that a new working group will start its work from the place where
that ad hoc working group left off, so it should not be necessary
to remind them formally of the content of that report.
If comments are to accompany the US response, the following
paragraph is being suggested. It is written to go with either a
positive or negative vote on whether the description of the NWI
is sufficient or not. This paragraph was not reviewed at the
meeting, but has been informally reviewed with some of the
members to be sure that it represents the views that were
expressed at the meeting and serves as an appropriate choice in
the context of this ballot.
Proposed Comments
In the US there is a very strong feeling that "Lisp" is the
name of a family of languages and that it is appropriate to
standardize only on a particular dialect and that the name
of this dialect must be part of the name of the standard. A
name like "ISO Lisp 89" would be too broad and would not
answer the concerns expressed here. Within the Lisp family,
there have existed many popular dialects with fundamental
differences in their design, implementation, and use. While
some of these existing differences may be resolved, others
will certainly appear since the Lisp family encourages such
experimentation and development.
The US concern about the name for the resulting ISO standard
and the wording of this proposed new work item is not a
shallow comment about words only, but is an indication of
our deep concern that the goals and objectives of developing
a standard within the Lisp family should not interfere with
continued developments in other parts of the Lisp family of
languages. This is one of the first issues that must be
considered by an ISO working group resulting from the
approval of this new work item. This naming issue was also
raised as part of the report of the SC22 ad hoc working
group (ISO/TC97/SC22 N 266) that lead to this NWI proposal.
The US feels that report should be one of the initial
documents of the working group resulting from this NWI
proposal and that the various issues it raises be addressed.
Some people felt that these concerns and opinions were well known
and accepted within the Lisp community; and that it was always
the case that a standards working group had to spend some of its
initial time agreeing on specifics of purposes and objectives; so
it was not necessary to formally state these issues in the US
reponse to TC97. "If 'it goes without saying,' it goes without
saying." On the other hand there is the view that it is just such
"obvious" things that need to be put down for the record so that
the work can proceed. As the discussion went on, comments
intended to support not making any formal comments were returned
as "exactly the reasons we should comment," and vice versa.
This is the central issue that motivated this mail ballot and is
Question 3 on the enclosed ballot -- should these concerns be
made a formal part of the US response or not. The other questions
are asked because of asking this one. You may of course have
other concerns and comments about this or other issues related to
this NWI, which you should include with your response.
The comments and discussion here (and any you formally send me)
will be seen by X3 members and their vote will determine what and
whether any comments will be forwarded to TC97 as part of the US
vote. This letter is being sent to everyone on the X3J13 mailing
list which includes many people who are likely to be on the ISO
working group; so these comments and concerns are being made
known. The issue is primarily whether or not they will be made a
part of the formal and official US response to ISO/TC97.
Besides summarizing the issues and the discussion, I also want to
give you an indication of the way I think the people at the
meeting felt. The questions were not put to them in exactly the
way they are here, not everyone at the meeting will be able to
vote in this mail ballot, not everyone entitled to vote was at
the meeting, and some people have probably changed their mind
since they last expressed their opinion to me; but I think most
of the people would have voted on the questions here in one of
the following three ways, with the first one listed being the
most popular and the last one the least popular, but with none of
them having a majority.
First Option: 1. yes 2. yes 3. no
Second Option: 1. yes 2. yes 3. yes
Third Option: 1. yes 2. no 3. yes
(If you notice the Gray code nature of the above, you may also
have some insight into why this was not decideable at the meeting
and is being submitted to a mail ballot.) If you want to choose
one of these options, you can respond electronically on this
ballot to Mathis@Ada20.isi.edu.
Comments are required with "No" votes. Since I have tried to give
the reasons for voting either direction, I assume some of you
will make your decision for basically the reasons described here,
so I have split the "No" choice into two parts for Questions 2
and 3 -- the first being "No" for the reasons given in this
letter and the second being "No" for other/additional reasons (in
which case you must give them).
As to the other items on the ISO ballot (Q.3 -- Q.7) the answers
are all "YES." [Q.3] The US is prepared to actively participate
in this work. [Q.4] We already have at least six people who are
members of X3J13 who are interested in serving on an ISO working
group. They have the technical background and the resources to
make effective contributions. Their participation in this new
working group would not detract from any existing TC97 related
work. [Q.5] The book Common Lisp: The Language by Guy L. Steele
Jr. is already listed as a reference on the NWI proposal. X3J13
has also been working on proposals for an object system, an
errors and conditions system, interfaces with window systems,
iteration mechanisms, conformance and validation, various issues
related to the Steele book, the Lisp1/Lisp2 issue, and many
others. [Q.6] These and other US documents will be made available
to the ISO Working Group as soon as it is formed and continually
in the future. [Q.7] Richard Gabriel and William Clinger have
expressed their willingness and are arranging the support
necessary for them to take on the role of project editor for this
work. They are both well known in the Lisp community and
respected for their insight into Lisp issues and their writing
abilities.
It is the desire and intention of X3J13 to be as open and
communicative as possible with the ISO work. X3J13 will continue
to be very active in working toward a standard that serves the
needs of the US and Common Lisp communities. Relevant documents
(from whatever source) will be circulated to both X3J13 and the
ISO working group.
Remember that this letter, a copy of the ballot, a summary of the
voting, and any comments you submit will be forwarded as a
package to X3 for their consideration (and to the X3J13 mailing
list as well of course). Even though I have tried to be objective
in these summaries, some of you may want to comment on any part
of my letter, the ballot issues, or the position X3 should take.
Such comments are part of the public standards process. I also
want to remind you that you may want to directly contact the X3
member from your company or organization.
If you have any questions about your responsibilities and/or
rights related to this ballot or if any of the issues are still
unclear, please contact me at Mathis@Ada20.isi.edu or (703)425-
5923.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
X3J13 Ballot on
Proposed NWI on Programming Language LISP (TC97 N 1929)
Deadline: Noon July 28, 1987 to Bob Mathis
(electronic response possible see p. 4)
Question 1: X3J13 recommends to X3 a "YES" vote on the "Proposed
NWI on Programming Language LISP (TC97 N 1929)"
YES NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
Question 2: X3J13 recommends to X3 a "YES" vote that the proposal
in TC97 N 1929 is a sufficient definition of the new work item.
YES NO (for the reasons stated in X3J13/87-030's summary
of the issues and discussions)
NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
Question 3: X3J13 recommends that the "Proposed Comments" on
page 3 of X3J13/87-030 be attached as formal comments with the
US response to ISO/TC97 on this Proposed NWI. (An X3 vote of "NO"
to the sufficiency of definition will require that comments be
provided to TC97, but you may suggest ones other than those in
X3J13/87-030.)
YES NO (because YES votes on the previous two questions
will need no comments)
NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu "Iteration" activity
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87 21:32:01 PDT
Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:27:53 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05324; Fri, 17 Jul 87 12:30:44 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00277; Fri, 17 Jul 87 12:34:45 PDT
Date: Fri, 17 Jul 87 12:34:45 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707171934.AA00277@bhopal.edsel.uucp>
To: labrea!x3j13%SAIL@labrea.stanford.edu
Subject: "Iteration" activity
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.
The large LOOP document I informally passed out at the Boston meeting
is a "reference" manual, and as such was intended for scrutiny by those
who are already are MIT-style LOOP lovers. Unfortunately, it seems to
be too much to digest for the novice, so I've prepared a 1-page "Blurb"
and a 1-page "Crib Sheet" to assist the kind of person who doesn't want
to be a LOOP wizard, but may want to have a working knowledge of it
[e.g., to read other people's code, or just to understand this common
but not universal iteration paradigm].
I would like to put this short document formally before the committee
as a readable report on the syntax and semantics of the MIT-style LOOP.
The next message from me to X3J13 will be three pages which are the text
of a "Blurb" (short, working-knowledge overview), a "Crib Sheet" (BNF
syntax with examples for most usages), and a set of two larger examples.
These three pages would be "hardcopied" by printing the "Blurb" in two
columns, 72 lines per column, landscape orientation, on one side of a
sheet, with the "Crib Sheet" similarly printed on the other side. The
"LOOP Examples" page may be viewed as a pop quiz, to see if you can
actually read production-level LOOP code.
Other iteration committee members have indicated they would submit some
additional material for X3J13 consideration, but time constraints seem to
have postponed them [e.g., Chris Perdue wanted to describe an Alphard-
style system, and Pavel Curtis had some ideas on changing or extending
the "collector" syntax of the MIT-style LOOP]. There is also some
question about whether or not to put the LETS reference manual and
code into the X3J13 arena; its size is comparable to that of LOOP, and
as yet we don't have any serious advocates for it on the committee.
-- JonL --
∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu LOOP "Blurb & Crib Sheet"
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87 21:32:15 PDT
Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:27:58 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05329; Fri, 17 Jul 87 12:32:41 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00290; Fri, 17 Jul 87 12:36:46 PDT
Date: Fri, 17 Jul 87 12:36:46 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707171936.AA00290@bhopal.edsel.uucp>
To: labrea!x3j13%SAIL@labrea.stanford.edu
Subject: LOOP "Blurb & Crib Sheet"
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.
LOOP Iteration Macro BLURB
WHAT IT IS:
LOOP syntax is an extension of the Common Lisp LOOP macro (CLtL, p 121), and
is expanded into other simpler Common Lisp primitives; the LOOP facility may
thus be thought of as a parser (or as a compiler) into more primitve lisp.
Parsing is controlled by Loop token words, which are simply symbols like FOR,
UNTIL, MAXIMIZE etc. A list of the more common Loop token words, along with
their syntax of usage, appears in the attached "CRIB SHEET".
HOW TO PARSE (and "READ") LOOP CLAUSES:
Each syntactic part of a LOOP construct is called a "clause," whose scope
is determined by the top-level parsing of the Loop token words. This
example contains a few of the possible clauses, to be explained below:
(LOOP FOR i FROM 1 TO (compute-top-value) ;first clause
WHILE (not (unacceptablep i)) ;second clause
COLLECT (square i) ;third clause
DO (format t "Working on ~D now" i) ;fourth clause
WHEN (evenp i) ;fifth clause
DO (format t "~D is a non-odd number" i)
FINALLY (format t "About to exit!!")) ;sixth clause
FROM and TO are also Loop token words, but they are auxiliaries to the FOR
clause. Just how many forms comprise a clause depends on the Loop token
word that starts the clause and on the auxiliary tokens connected with it.
ORDER OF EXECUTION:
Except as noted below, clauses are executed in the same order as they appear
in source code, just as if they were inside one big PROGN. This is repeated
over and over until some clause causes termination, or until a Lisp RETURN,
GO, or THROW, is executed. The exceptions to "linear order" are:
-- Variable initializations are all done first, regardless of where in
the loop body the clause that established the variable is located.
-- The INITIALLY clause (if any) is executed once, before cycling
through the rest of the code.
-- The FINALLY clause (if any) is executed once, before exiting, except
when the code is exited by a Common Lisp GO, RETURN, or THROW.
(Another exception is THEREIS/ALWAYS/NEVER clauses; see the Loop
reference manual for details).
-- Clauses labeled "Iteration Control" (such as FOR i from 1 to 10 ...)
implicitly cause:
+ a variable initialization to be done "initially";
+ a variable "stepping" to be done, generally, between
each execution of the PROGN-like loop body; and
+ a termination test to be performed, generally, just
before the execution of the loop body.
KINDS OF LOOP CLAUSES:
Clauses turn into Lisp code that falls into one of several categories:
** Variable initializating and possibly incrementing:
-- FOR (and its synonym AS) establish a variable to be initialized.
These are called "Iteration control" clauses, and are further
distinguished by auxiliary tokens such as IN, BY, FROM, etc.
FOR/AS clauses also produce code to re-initialize the variable
each time around the loop. When used with the auxiliary "=",
the same form used for the first initialization code is used for
the re-initialization code. With any auxiliary like FROM, UPTO,
DOWN, etc. the re-initialization is a numerical increment by INCF
(or by DECF) defaulting to 1, but changeable by auxiliary BY.
-- Multiple FOR/AS clauses may be combined either serially or
sequentially with the token AND (This is an advanced topic --
see the Loop reference manual for details.)
-- WITH is basically equivalent to a single LET clause. Multiple
WITH clauses may be combined either serially or sequentially
using the token AND (see the Loop reference manual for details).
** Value accumulation
-- COLLECT takes just one form in its clause, and tacks the value
of that form onto the end of a list of values to be returned
when the loop finishes.
-- APPEND is like collect except the value is considered to be
a list of zero or more individual values to be tacked on.
-- SUM takes just one form in its clause, which must evaluate to a
number; the sum of the numbers is returned when the loop finishes.
-- COUNT takes just one form in its clause, and counts the times it
evaluates to non-nil; the count is returned when the loop finishes.
-- MINIMIZE takes just one form in its clause, and keeps track of the
minimum value attained by evaluating that form; this minimum value
is returned when the loop finishes.
-- MAXIMIZE (similar to MINIMIZE).
-- THEREIS, explained below, will cause the non-null value of its
termination predicate to be returned; **however** termination
may occur due to some other clause, in which case the THEREIS
clause does not affect anything.
-- <...>ING -- most of these token words can also be suffixed with ING
** Termination conditions
-- (LOOP-FINISH) is a macro (rather than a token word or clause)
essentially equivalent to a RETURN out of the loop. However,
an accumulated value (if any) is returned instead of nil, and a
FINALLY clause (if any) is also executed.
-- FOR/AS clauses contribute a termination test determined by
the nature of the "Iteration control"
-- WHILE takes just one form, <condition>, in its clause and is
equivalent to the code: (if (not <condition>) (loop-finish)).
-- UNTIL is an inverse of WHILE: (if <condition> (loop-finish)).
-- THEREIS, like UNTIL, takes just one form in its clause, and causes
termination whenever that form evaluates to non-nil; unlike UNTIL,
it does not call (LOOP-FINISH), but directly returns the non-null
value from its form.
-- ALWAYS is like WHILE, but directly returns NIL whenever its
<condition> form evaluates to "false" (i.e., nil).
-- NEVER is like WHILE, but directly returns NIL whenever its
<condition> form evaluates to "true" (i.e., non-nil).
** Unconditional execution
-- DO clauses include all forms up to the next Loop token word;
they are all executed each time around the loop body.
-- DOING is a synonym for DO.
** Conditionals
-- IF clauses take one form as a predicate, and a subsequent value
accumulation clause (or DO or nested conditional clause) that
is executed during the loop body phase if the predicate is true.
-- WHEN is a synonym for IF.
-- UNLESS is like WHEN, but complements the predicate.
-- an ELSE clause is an optional component of an IF, WHEN, or UNLESS
clause, and is executed when the predicate is false.
KINDS OF ITERATION CONTROLS
** Iterating over integers, including or not including the endpoint:
(loop for i from 1 to 10 do ...) ;range includes 1, 2, ... and 10
(loop for i from 1 below 10 do ...) ; includes 1, 2, ... but not 10
(loop for i upto 10 do ...) ; includes 0 (default) ... and 10
(loop for i from 10 above 1 do ...) ; includes 10, 9 , 8 ... but not 1
(loop for i below 10 do ...) ; includes 0 (default) ... not 10
** Iterating over lists
(loop for item in baz-list do ...) ;somewhat like dolist
(loop for tail on baz-list do ...) ;somewhat like maplist
(loop for item in baz-list by #'cddr do ...) ;skips alternate items
** Iterating over Common Lisp sequences (access via ELT):
(loop for a being the elements of <some-sequence> ...)
** Repeated setting of variable to same evaluation:
(loop for x = (read-char) until (funny-char-p x) do (process-char x))
** Value on first time computed differently than on subsequent iterations:
(loop for x = #\( then (read-char) ...)
;; First time, x is set to #\(; subsequent times it calls read-char.
DESTRUCTURING and TYPE DECLARATIONS
A list may be used whereever a variable is called for, and the value for
that "variable" will be "destructured" (see CLtL, p146). Variables may
be followed by optional type specifiers, which are limited to FIXNUM
INTEGER, NUMBER, NOTYPE, T and the floating-point types. These are
considered advanced topics; see the Loop reference manual for details.
!
LOOP Iteration Macro CRIB SHEET
Below is an abbreviated list of the more commonly used LOOP syntax tokens
(sometimes called "Loop Keywords"); a BNF description of the legal format
is given, along with an example for each one.
Iteration Control
------------------------------------------------------------------------------
FOR <var> [{FROM | DOWNFROM | UPFROM} <expr1>]
[{TO | DOWNTO | UPTO | BELOW | ABOVE} <expr2]
[BY <expr3>]
(loop for i integer from 0 to 10 by 2
do (format t "~A" i)) ==> 0 2 4 6 8 10
(loop for i downfrom 6 above 0
do (format t "~A" i)) ==> 6 5 4 3 2 1
FOR <var> IN <expr1> [BY <step-function>]
(loop for i in '(1 2 3) sum i) ==> 6
FOR <var> ON <expr1> [BY <step-function>]
(loop for (i) on '(1 2 3) sum i) ==> 6
FOR <var> FIRST <expr1> THEN <expr2>
FOR <var> = <expr1> [THEN <expr2>]
(loop for i first 2 then (* i i)
until (> i 500)
collect i) ==> (2 4 16 256)
(loop for i = (read-char)
until (eql i #\newline)
collect i) ==> (#\a #\b ...)
FOR <var> BEING EACH ELEMENT OF <sequence>
FOR <var> BEING THE ELEMENTS OF <sequence>
(loop for dollars being each element of #(2 9 4 6)
sum dollars) ==> 21
(loop for char being the elements of (the simple-string "abcd")
collect char) ==> (#\a #\b #\c #\d)
AS is a synonym for FOR
REPEAT
(loop repeat 3 (print "What I say three times it true"))
==> "What I say three times it true"
"What I say three times it true"
"What I say three times it true"
End-Test Control
------------------------------------------------------------------------------
THEREIS <predicate>
(loop for i upfrom 0 thereis (and (> i 10) i)) ==> 11
ALWAYS and NEVER are similar to THEREIS:
(loop for i from 0 to 10 by 3 always (< i 10)) ==> T
(loop for i from 0 to 9 by 3 always (< i 9)) ==> NIL
(loop for i from 0 to 10 never (> i 11)) ==> T
LOOP-FINISH
(loop for i from 1 to 10
do (format t "~A " i)
(loop-finish)) ==> 1
WHILE <predicate>
UNTIL <predicate>
(loop while (hungry-p) do (eat))
(loop until (not (hungry-p)) do (eat))
Value Accumulation
------------------------------------------------------------------------------
COLLECT <item> [INTO <var>]
(loop for i from 1 to 5 collect i) ==> (1 2 3 4 5)
APPEND <list> [INTO <var>]
(loop for i in '((a) (b) ((c) d)) append i) ==> (A B (C) D)
NCONC is similar to append, but uses NCONC function rather than APPEND.
SUM <number> [INTO <var>]
(loop for i in '(1 2 3 4 5)
sum i into lots
finally (return (list lots lots))) ==> (15 15)
COUNT <form> [INTO <var>]
(loop for i in '(a 2 nil c t "x") count i) ==> 5
;; Remember -- nil is not counted
MAXIMIZE <expr> [INTO <var>]
MINIMIZE <expr> [INTO <var>]
(loop for i in '(2 1 5 3 4)
maximize i into moby
finally (cogitate-upon moby)) ==> NIL
;; No automatic return value, bug 'cogitate-upon'
;; is called with value 5 in the finally clause.
Binding Variables
------------------------------------------------------------------------------
WITH <var> [= <initial-value>]
(loop with x = 10
for i from 1 to 3
do (format t "~A " x)) ==> 10 10 10
Conditional Execution
------------------------------------------------------------------------------
<c-clause> ::=
{ DO <form>+ | {COLLECT <item> | APPEND <list> | SUM <number> | etc.} }
IF <predicate> <c-clause> [ELSE <c-clause>]
WHEN <predicate> <c-clause> [ELSE <c-clause>]
(loop for i from 1 to 10
if (< i 5)
do (format t "~A " i)
else
do (format t "*")) ==> 1 2 3 4 *****
UNLESS <predicate> <c-clause> [ELSE <c-clause>]
(loop for i from 1 to 10 unless (< i 5) count i) ==> 6
Unconditional Execution
------------------------------------------------------------------------------
DO <form>+
(loop for i from 16 to 18
do (format t "~D " i)
(format t "~X " i)) ==> 16 10 17 11 18 12
Initial and Final Evaluation
------------------------------------------------------------------------------
INITIALLY <form>
(loop initially (format t "++ ")
for i from 1 to 5
do (format t "~A " i)) ==> ++ 1 2 3 4 5
FINALLY <form>
(loop finally (format t "++")
for i from 1 to 5
do (format t "~A " i)) ==> 1 2 3 4 5 ++
!
LOOP EXAMPLES
Since the LOOP facility is implemented as an ordinary Common Lisp macro,
it is often instructive to call MACROEXPAND-1 on a LOOP expression to
see how it gets translated into "vanilla" code. In the example below,
the goal of the loop is to find the tail of '*temporary-code*' just before
the cell that contains a suitable code-vector; this cell will subsequently
be "spliced" out of the *temporary-code* list.
(macroexpand-1 '(loop initially (setq temp-cell *temporary-code*)
while (not (null (rest temp-cell)))
thereis (<=& len (code-length (second temp-cell)))
do (pop temp-cell)))
==>
(let ((#:it1 nil))
(block nil
(tagbody
(setq temp-cell *temporary-code*)
loop::begin-loop
(unless (not (null (rest temp-cell)))
(loop-finish))
(when (setq #:it1 (<=& len (code-length (second temp-cell))))
(return #:it1))
(pop temp-cell)
(go loop::begin-loop)
loop::end-loop)))
Here is another realistic, complex example taken from one version of the
Lucid debugging module. Notice how the essential control parts of the loop
structure are highlighted by being at "top level":
-- there are few (if any) hidden exits from the loop.
-- Numerical "stepping" is invoked by a very succinct, stylized syntax
reminiscent of mathematical notation, rather than the cumbersome,
and distributed, code parts for Common Lisp DO.
-- "stepping" that doesn't fit into the provided formats can be
modeled by a three-line sequence of WITH/DO/WHILE clauses.
(loop for i upfrom (- frames-to-skip) ;'i' < 0 while skipping; and
below (or limit infinity) ; maybe there's no limit?
with fp = first-fp ;'fp' will chain through
do (setq fp (next-valid-fp ; the sequence of valid
fp ; stack frame pointers.
stack-bottom
report-problems))
while fp ;End of stack? if so, exit now
when (and table-length ;Make sure frame fits
(>= i table-length))
do (format *error-output* ;foo
"Error collecting stack frames")
(loop-finish)
when (and (>= i 0) ;Not skipping
frame-environment) ;Want frame recorded?
do (setf (stack-frame-fp i frame-environment)
fp)
finally (return ;Return # of non-skipped frames
;;I points to the first unused slot in all exit cases,
;;so I is the number of frames stored (or counted)
(max i 0)) ;But never negative
)
∂22-Jul-87 0741 FAHLMAN@C.CS.CMU.EDU Iteration proposals
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Jul 87 07:41:25 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 22 Jul 87 10:36:19-EDT
Date: Wed, 22 Jul 1987 10:36 EDT
Message-ID: <FAHLMAN.12320403233.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: x3j13@SAIL.STANFORD.EDU
Subject: Iteration proposals
I have a few comments on Loop and the other iteration proposals, but I
assume that this is not the proper forum for detailed discussions,
especially of a preliminary nature. Is the iteration subcommittee now
active, with an internal communication channel for this stuff?
-- Scott
∂23-Jul-87 0944 edsel!bhopal!jonl@labrea.stanford.edu Iteration proposals
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 09:44:42 PDT
Received: by labrea.stanford.edu; Thu, 23 Jul 87 09:40:32 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA01235; Wed, 22 Jul 87 19:49:39 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03169; Wed, 22 Jul 87 19:49:57 PDT
Date: Wed, 22 Jul 87 19:49:57 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707230249.AA03169@bhopal.edsel.uucp>
To: labrea!Fahlman%C.CS.CMU.EDU@labrea.stanford.edu
Cc: labrea!x3j13%sail@labrea.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Wed, 22 Jul 1987 10:36 EDT <FAHLMAN.12320403233.BABYL@C.CS.CMU.EDU>
Subject: Iteration proposals
At the Palo Alto X3J13 meeting in mid-March, Chris Perdue offered to set up a
mail redistribution list for the iteration sub-committee, at Sun. After a
few false starts, I think some mail successfully was forwarded through
"sun!clam!loop-groop"; but about mid-May, several of the committee members
fell into the proverbial black hole of "other committments", and there
haven't been any mailings through that channel since then.
None of the iteration committe members were present at the Boston meeting
except myself (and you weren't there either?); so we didn't even have our
face-to-face meeting, as planned. For the time being, I guess individual
contact is still the only active channel; the addresses, as last I knew
them, were:
edsel!jonl@labrea.stanford.edu (Jon L White)
DLW@SCRC.Symbolics.COM (Dan Weinreb)
cperdue@sun.COM (Chris Perdue)
Pavel.pa@Xerox.COM (Pavel Curtis)
GSB@mc.lcs.mit.edu (Glenn Burke)
-- JonL --
∂14-Aug-87 0803 @HAL.CAD.MCC.COM:Loeffler@MCC.COM Windows Subcommittee
Received: from [128.62.1.126] by SAIL.STANFORD.EDU with TCP; 14 Aug 87 08:00:52 PDT
Date: Fri, 14 Aug 87 09:42 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Windows Subcommittee
To: X3j13@sail.stanford.edu
cc: Loeffler@MCC.COM
Message-ID: <870814094226.6.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
What is the current status of the windows committee? I have two people
here at MCC that would like to participate.
-- David D. Loeffler
∂15-Sep-87 0424 MATHIS@ADA20.ISI.EDU report on ISO NWI and SC22 meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 87 04:24:36 PDT
Date: 14 Sep 1987 19:53-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: report on ISO NWI and SC22 meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU]14-Sep-87 19:53:33.MATHIS>
At our meeting in Boston in July, the proposed New Work Item for an
international standard for Lisp was discussed. After a mail ballot of the
membership, it was decided (and subsequently endorsed by X3, the parent
committee of X3J13 and the organization responsible for the final US vote on
this issue) to forward the following comments with our ballot:
In the US there is a very strong feeling that "Lisp" is the
name of a family of languages and that it is appropriate to
standardize only on a particular dialect and that the name
of this dialect must be part of the name of the standard. A
name like "ISO Lisp 89" would be too broad and would not
answer the concerns expressed here. Within the Lisp family,
there have existed many popular dialects with fundamental
differences in their design, implementation, and use. While
some of these existing differences may be resolved, others
will certainly appear since the Lisp family encourages such
experimentation and development.
The US concern about the name for the resulting ISO standard
and the wording of this proposed new work item is not a
shallow comment about words only, but is an indication of
our deep concern that the goals and objectives of developing
a standard within the Lisp family should not interfere with
continued developments in other parts of the Lisp family of
languages. This is one of the first issues that must be
considered by an ISO working group resulting from the
approval of this new work item. This naming issue was also
raised as part of the report of the SC22 ad hoc working
group (ISO/TC97/SC22 N 266) that lead to this NWI proposal.
The US feels that report should be one of the initial
documents of the working group resulting from this NWI
proposal and that the various issues it raises be addressed.
Other countries have also submitted comments -- France offered a Convenor,
Japan thought there should be more emphasis on Common Lisp, and the United
Kingdom emphasized the need for a single standard.
ISO/IEC JTC1/SC22 (the SubCommittee on Languages of Joint Technical Committee
1 of the International Organization for Standardization and the International
Electrotechnical Commission) decided to form Working Group 16 on Lisp.
Christian Queinnic was named Convenor and Richard Gabriel and William Klinger
were named as project editors.
At that same meeting there was considerable discussion about the handling of
large character sets in programming languages. While this issue is frequently
thought of in terms of handling Japanese and Chinese, it is also important for
European languages other than English and for modern text manipulation
systems.
The first meeting of WG 16 will be held February 24 and 25, 1988, in Paris,
France. There will be an International Workshop on Lisp Evolution and
Standardization on February 22 and 23, also in Paris. Participation in the
Workshop is separate from participation in the ISO/IEC Working Group.
∂15-Sep-87 0929 dcm%hpfclp@hplabs.HP.COM October X3J13 meeting
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 87 09:28:34 PDT
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Tue, 15 Sep 87 10:27:15 mdt
Received: from hpfcdcm by hpfcdcm.HP.COM; Tue, 15 Sep 87 10:27:41 mdt
Return-Path: <dcm@hpfcdcm>
Message-Id: <8709151627.AA15748@hpfcdcm.HP.COM>
To: x3j13@sail.stanford.edu
Cc: mathix@ada20.isi.edu
Subject: October X3J13 meeting
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Tue, 15 Sep 87 10:27:37 MST
Sender: dcm%hpfclp@hplabs.HP.COM
X3J13 Meeting
10/20/87 - 10/21/87
Fort Collins, Colorado
The fifth meeting of X3J13 will be held Monday through Wednesday,
October 19-21 at the University Park Holiday Inn in Fort Collins,
Colorado. Monday has been set aside for committee meetings, followed
by the main meeting on Tuesday and Wednesday. October is the perfect
time to see fall (and sometimes winter) in Colorado. Rocky Mountain
National Park is approximately one hour from Fort Collins.
Hewlett-Packard's travel affiliate, Lifeco Travel, has negotiated
discount airfares that you can obtain by calling:
800-521-8858 (in California)
800-722-8755 (elsewhere)
Ask to make a group reservation for X3J13. You may also make your
room, rental car, or airport limousine reservations through Lifeco at
the same time. Payment must be made by credit card. Tickets will be
mailed via registered mail. Late reservations can be express mailed
at additional cost.
A block of rooms is available at the University Park Holiday Inn at
$46.50 plus tax per night. If you don't make reservations through
Lifeco Travel, please make your own reservations by calling
(303)482-2626 and asking to reserve a room in the "HP X3J13" block.
Reservations will be held until 6 PM unless guaranteed by a major
credit card. Non-smoking rooms are available. Check-in and check-out
times are 1 PM. The block of rooms will be dropped on 10/2/87, but
you should still be able to obtain the discounted room rate on
available rooms if you specify you are attending the the "HP X3J13"
conference.
Refreshments and lunch are being arranged for Tuesday and Wednesday.
I expect these arrangements will run $50 or less per person which I
will collect at the meeting. I should be able to update this value in
a few weeks. Please note any dietary restrictions so I can make the
necessary arrangements with the catering department.
If there is sufficient interest I would like to arrange a dinner
Tuesday evening at Cuisine, Cuisine. Cuisine, Cuisine is an intimate
cafe offering some the best and most unusual food in Northern
Colorado. It is a very small cafe which can only accommodate 60 total
patrons, but they are willing to put together a special banquet for
us. To handle a group this large in a short period of time they would
like to limit the menu to 4 items. The list of possible entrees
includes: Cajun roast duckling with spice peach gravy, chicken boursin
(double breast of chicken stuffed with herbed cream cheese dressing
and mushroom voloute' sauce), shrimp diane (sauteed jumbo shrimp in a
garlic cajun sauce), sirloin tips with mushrooms and onions, poached
salmon with a special sauce, or boned leg of lamb stuffed with spinach
and served with a dijon sauce. A vegetarian entree will also be
available. Entrees would be about 15 dollars, including soup or
salad. Appetizers, dessert, and beverage would be ala carte.
Cuisine, Cuisine accepts charge cards, but cash would also be welcome.
I would need to narrow this to the four items at least 2 weeks in
advance so they could make the necessary preparations. Note if you
are interested on the registration form and mark your first and second
choice entrees. Please note any dietary restrictions if this
selection is not sufficient.
Fort Collins is approximately a one hour drive from Denver's Stapleton
International Airport. From the airport take I-270 or I-70 west to
I-25 and go north on I-25 towards Cheyenne, Wyoming. Take the first
Fort Collins exit, #265, turn left and drive 5 miles to the College
Avenue intersection. Turn right and drive 3 miles to the Prospect
Road intersection. Turn left and the Holiday Inn is just across the
railroad tracks on the south side of the road. It shouldn't be hard
to see since it is 8 stories tall in an area with very few building
over 2 stories.
Two limousine services provide shuttle service from Stapleton directly
to the Holiday Inn. Fort Collins Express (303-482-0505) leaves
Stapleton on the hour while the Front Range Airporter (303-221-5466)
leaves Stapleton on the half hour. Both are located in the baggage
claim area. The charge is $12 each way on the Express and $13 on the
Airporter.
| Prospect Road ||
=========|====================== ||
HI | ||
M | ||
O | ||
U | ||
N | Drake Road North ||
T =========|====================== /\ ||
A | || ||
I |US 287/ College Avenue ||
N | ||I-25
S | ||
| Horsetooth Road ||
=========|====================== ||
| ||
| ||
| ||
| ||
| Harmony Road HP /||\
=========|=============================================||===========
| \||/ Exit 265
| ||
||
\/
Denver
Please return the following registration form by October 5 via
electronic mail to dcm%hpfclp@hplabs.hp.com or via US Mail to:
Dave Matthews
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado 80525
(303)339-2201
Feel free to contact me if you have any questions
__________________________________________________________________________
X3J13 OCTOBER MEETING REGISTRATION FORM
Name: __________________________________________________
Institution: __________________________________________________
Street Address: __________________________________________________
City, State, Zip: __________________________________________________
Phone: __________________________________________________
Network Address: __________________________________________________
Dinner 10/20 (y/n): __________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂16-Sep-87 1145 dcm%hpfclp@hplabs.HP.COM November X3J13 meeting
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 87 11:45:10 PDT
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Wed, 16 Sep 87 12:43:25 mdt
Received: from hpfcdcm by hpfcdcm.HP.COM; Wed, 16 Sep 87 12:43:23 mdt
Return-Path: <dcm@hpfcdcm>
To: x3j13@sail.stanford.edu
Cc: mathis@ada20.isi.edu, dcm%hpfcdcm@hplabs.HP.COM
Subject: November X3J13 meeting
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Wed, 16 Sep 87 12:43:19 MST
Message-Id: <1297.558816199@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
Bob Mathis requested that I delay the meeting a month so the subcommittees
will have more time to prepare their reports. I have rescheduled the
meeting a month later, November 16-18, which seemed to be the most
desirable dates in November. Other than the date changes there are no
other changes in the arrangements.
Dave Matthews
--------------------------------------------------------------------------
X3J13 Meeting
11/16/87 - 11/18/87
Fort Collins, Colorado
The fifth meeting of X3J13 will be held Monday through Wednesday, November
16-18 at the University Park Holiday Inn in Fort Collins, Colorado. Monday
has been set aside for committee meetings, followed by the main meeting on
Tuesday and Wednesday. November is the perfect time to see fall (and
sometimes winter) in Colorado. Rocky Mountain National Park is
approximately one hour from Fort Collins.
Hewlett-Packard's travel affiliate, Lifeco Travel, has negotiated discount
airfares that you can obtain by calling:
800-521-8858 (in California)
800-722-8755 (elsewhere)
Ask to make a group reservation for X3J13. You may also make your room,
rental car, or airport limousine reservations through Lifeco at the same
time. Payment must be made by credit card. Tickets will be mailed via
registered mail. Late reservations can be express mailed at additional
cost.
A block of rooms is available at the University Park Holiday Inn at $46.50
plus tax per night. If you don't make reservations through Lifeco Travel,
please make your own reservations by calling (303)482-2626 and asking to
reserve a room in the "HP X3J13" block. Reservations will be held until 6
PM unless guaranteed by a major credit card. Non-smoking rooms are
available. Check-in and check-out times are 1 PM. The block of rooms will
be dropped on 11/2/87, but you should still be able to obtain the
discounted room rate on available rooms if you specify you are attending
the the "HP X3J13" conference.
Refreshments and lunch are being arranged for Tuesday and Wednesday. I
expect these arrangements will run $50 or less per person which I will
collect at the meeting. I should be able to update this value in a few
weeks. Please note any dietary restrictions so I can make the necessary
arrangements with the catering department.
If there is sufficient interest I would like to arrange a dinner Tuesday
evening at Cuisine, Cuisine. Cuisine, Cuisine is an intimate cafe offering
some the best and most unusual food in Northern Colorado. It is a very
small cafe which can only accommodate 60 total patrons, but they are
willing to put together a special banquet for us. To handle a group this
large in a short period of time they would like to limit the menu to 4
items. The list of possible entrees includes: Cajun roast duckling with
spice peach gravy, chicken boursin (double breast of chicken stuffed with
herbed cream cheese dressing and mushroom voloute' sauce), shrimp diane
(sauteed jumbo shrimp in a garlic cajun sauce), sirloin tips with mushrooms
and onions, poached salmon with a special sauce, or boned leg of lamb
stuffed with spinach and served with a dijon sauce. A vegetarian entree
will also be available. Entrees would be about 15 dollars, including soup
or salad. Appetizers, dessert, and beverage would be ala carte. Cuisine,
Cuisine accepts charge cards, but cash would also be welcome.
I would need to narrow this to the four items at least 2 weeks in advance
so they could make the necessary preparations. Note if you are interested
on the registration form and mark your first and second choice entrees.
Please note any dietary restrictions if this selection is not sufficient.
Fort Collins is approximately a one hour drive from Denver's Stapleton
International Airport. From the airport take I-270 or I-70 west to I-25
and go north on I-25 towards Cheyenne, Wyoming. Take the first Fort
Collins exit, #265, turn left and drive 5 miles to the College Avenue
intersection. Turn right and drive 3 miles to the Prospect Road
intersection. Turn left and the Holiday Inn is just across the railroad
tracks on the south side of the road. It shouldn't be hard to see since it
is 8 stories tall in an area with very few building over 2 stories.
Two limousine services provide shuttle service from Stapleton directly to
the Holiday Inn. Fort Collins Express (303-482-0505) leaves Stapleton on
the hour while the Front Range Airporter (303-221-5466) leaves Stapleton on
the half hour. Both are located in the baggage claim area. The charge is
$12 each way on the Express and $13 on the Airporter.
| Prospect Road ||
=========|====================== ||
HI | ||
M | ||
O | ||
U | ||
N | Drake Road North ||
T =========|====================== /\ ||
A | || ||
I |US 287/ College Avenue ||
N | ||I-25
S | ||
| Horsetooth Road ||
=========|====================== ||
| ||
| ||
| ||
| ||
| Harmony Road HP /||\
=========|=============================================||===========
| \||/ Exit 265
| ||
||
\/
Denver
Please return the following registration form by November 2 via electronic
mail to dcm%hpfclp@hplabs.hp.com or via US Mail to:
Dave Matthews
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado 80525
(303)339-2201
Feel free to contact me if you have any questions.
__________________________________________________________________________
X3J13 NOVEMBER MEETING REGISTRATION FORM
Name: __________________________________________________
Institution: __________________________________________________
Street Address: __________________________________________________
City, State, Zip: __________________________________________________
Phone: __________________________________________________
Network Address: __________________________________________________
Dinner 11/17 (y/n): __________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂24-Sep-87 0312 @RELAY.CS.NET:yuasa%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Japanese Activities toward Lisp Standardization
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 24 Sep 87 03:12:38 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa25268; 24 Sep 87 6:13 EDT
Received: from utokyo-relay by RELAY.CS.NET id ay09298; 24 Sep 87 6:00 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA23717; Thu, 24 Sep 87 17:39:32 JST
Received: by titcca.cc.titech.junet (4.12/6.2Junet)
id AA00464; Thu, 24 Sep 87 17:14:20 jst
Received: by nttlab.NTT (4.12/6.2NTT.g) with TCP; Thu, 24 Sep 87 15:58:47 jst
Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet)
id AA16011; Thu, 24 Sep 87 14:50:53 jst
Received: by kurims.kurims.kyoto-u.junet (3.2/6.2Junet)
id AA01964; Thu, 24 Sep 87 14:37:43 JST
Date: Thu, 24 Sep 87 14:37:43 JST
From: Taiichi Yuasa <yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <yuasa@kurims.kurims.kyoto-u.junet>
Message-Id: <8709240537.AA01964@kurims.kurims.kyoto-u.junet>
To: x3j13@SAIL.STANFORD.EDU
Subject: Japanese Activities toward Lisp Standardization
Japanese Activities toward Lisp Standardization
The demand for Lisp standardization has been growing rapidly in Japanese
computer industries and academic organizations. AIST (Agency of Industrial
Science and Technology), which is responsible for Japan Industrial Standards
(JIS in short), has initiated its activity toward JIS Lisp standardization.
In April 1986, in response to the request from AIST, a working group for Lisp
standardization was formed at JEIDA (Japan Electronic Industry Development
Association). After one year's preliminary discussions, the following
committee "JEIDA Committee for Lisp Standardization" was formed and its
active efforts have begun in June 1987. The aim of this committee is to
develop a Lisp language specification suitable for JIS standard in cooperation
with ISO and the organizations for Lisp standardization in other countries.
JEIDA Committee for Lisp Standardization
----------------------------------------
Chairman:
Takayasu Ito (Tohoku University)
Secretaries:
Tsuneo Furuyama (NTT: Nippon Telegraph and Telephone Corp.)
Fumio Motoyoshi (ETL: Electrotechnical Laboratory)
Taiichi Yuasa (Kyoto University)
Members from Major Computer Companies:
Fujitsu Ltd.
Hitachi Ltd.
IBM Japan Ltd.
Mitsubishi Electric Corp.
NEC Corp.
Oki Electric Industry Co. Ltd.
Toshiba Corp.
Observers:
Masayuki Ida (Aoyama Gakuin University)
Tetsuo Ida (The Institute of Physical and Chemical Research)
Ryo Kamito (AIST)
Masakazu Nakanishi (Keio University)
Takehisa Nireki (JEIDA)
Kentaro Shimizu (University of Tokyo)
Technical issues for Lisp standardization will be discussed by the subsidiary
working group "JEIDA Technical Working Group for Lisp Standardization", or
TG/A in short. This group started technical discussions soon after it was
formed in August 1987. It has been agreed that Common Lisp is a good starting
point for technical discussions. But various technical deficiencies of Common
Lisp have been already pointed out at TG/A. The role of TG/A is to clear up
major technical issues for Lisp standardization, continuing detailed technical
examinations on Common Lisp and other Lisp dialects.
JEIDA Technical Working Group for Lisp Standardization
------------------------------------------------------
Chairman:
Taiichi Yuasa (Research Institute for Mathematical Sciences,
Kyoto University)
Members:
Takashi Chikayama (ICOT)
Etsuya Shibayama (Dept. of Information Science,
Tokyo Institute of Technology)
Kentaro Shimizu (Dept. of Information Science, University of Tokyo)
Akikazu Takeuchi (Central Research Lab., Mitsubishi Electric Corp.)
Kyoji Umemura (NTT Software Lab., NTT)
Advisors:
Toshiaki Kurokawa (Tokyo Research Lab., IBM Japan Ltd.)
Michiaki Yasumura (Central Research Lab., Hitachi Ltd.)
Anyone interested in Japanese activities for Lisp standardization should
contact:
Professor Takayasu Ito
Department of Information Engineering
School of Engineering
Tohoku University
Sendai 980, Japan
Junet: chairlsp@nttlab.ntt.junet
or
Dr. Taiichi Yuasa
Research Institute for Mathematical Sciences
Kyoto University
Kyoto 606, Japan
Junet: yuasa@kurims.kurims.kyoto-u.junet
∂20-Oct-87 1636 @RELAY.CS.NET:DUSSUD@jenner.csc.ti.com Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Oct 87 16:36:09 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae00813; 20 Oct 87 18:19 EDT
Received: from csl.ti.com by RELAY.CS.NET id ah15609; 20 Oct 87 18:17 EDT
Received: from Jenner by tilde id AA13643; Tue, 20 Oct 87 16:18:06 CDT
Message-Id: <2770752076-11152612@Jenner>
Date: Tue, 20 Oct 87 16:21:16 CDT
From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
To: dcm%hpfclp@hplabs.hp.com
Cc: x3j13@SAIL.STANFORD.EDU
Subject: Re: November X3J13 meeting
In-Reply-To: Msg of Wed, 16 Sep 87 15:39:35 cdt from tilde::@relay.cs.net, @sail.stanford.edu:dcm%hpfclp@hplabs.hp.com
X3J13 NOVEMBER MEETING REGISTRATION FORM
Name: Patrick Dussud
Institution: Texas Instruments Austin.
Street Address: 12501 research Blvd
City, State, Zip: Austin TX 78759
Phone: (512) 250-7483
Network Address: Dussud%jenner%ti-csl.csnet
Dinner 11/17 (y/n): N__________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂22-Oct-87 0839 ROSENKING@A.ISI.EDU Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 22 Oct 87 08:39:11 PDT
Date: 22 Oct 1987 11:36-EDT
Sender: ROSENKING@A.ISI.EDU
Subject: November Meeting
From: ROSENKING@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]22-Oct-87 11:36:22.ROSENKING>
To all those planning to attend the November meeting:
If anyone is interested in indulging in some pre-meeting skiing, on
Saturday and Sunday (Nov. 14-15) at Breckenridge or Keystone mountains
in Colorado, drop me some mail. I am gathering accomodation and prime
ski condtion information at this time and I plan on making reservations
shortly.
All are welcome ! Lisp experience is a plus, though not for skiing ?!
- Jeff Rosenking
∂26-Oct-87 0522 MATHIS@C.ISI.EDU next meeting
Received: from C.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 05:21:58 PST
Date: 26 Oct 1987 05:21-PST
Sender: MATHIS@C.ISI.EDU
Subject: next meeting
From: MATHIS@C.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[C.ISI.EDU]26-Oct-87 05:21:15.MATHIS>
I hope you are all making your reservations for the next meeting,
Nov 16-18, in Colorado.
Messages about this were sent out to this list some time ago and
in the mail just recently.
Monday afternoon is for subcommittee meetings -- people who are
planning such should either respond to me directly or announce
them on this list.
Tuesday we will start about 9am.
Wednesday I would like to leave Denver about 7pm. That means the
meeting can run until 5pm. I expect that people will be staying
for the full afternoon. If a four o'clock ending time would
help, let me know so others can plan on it too.
As to the agenda -- I expect some discussion about windows on
Tuesday; some discussion about the Lisp1/Lisp2 issue; some
discussion about planning for the international work; more on
CLOS; and an extensive report from the clean-up committee (they
have been busy, but won't have their report mailed around in
advance). There are also other committees that will be
reporting.
If you have any suggestions for agenda organization, please let
me know. I will try to put out a more complete version by the
end of the week (if you get back to me).
Thanks, Bob
∂26-Oct-87 1233 MATHIS@C.ISI.EDU Wednesday afternoon agenda
Received: from C.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 12:33:31 PST
Date: 26 Oct 1987 12:32-PST
Sender: MATHIS@C.ISI.EDU
Subject: Wednesday afternoon agenda
From: MATHIS@C.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[C.ISI.EDU]26-Oct-87 12:32:47.MATHIS>
I have already gotten an indication from a few people that they
have to leave around 2pm or 3pm Wednesday afternoon. That's
fine. However, it might make sense to have the last item on the
Wednesday agenda be something that might be considered less
central to the overall work. Any suggestions?
Thanks, Bob
∂29-Oct-87 1212 X3J13-mailer November X3J13 meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 12:12:47 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Thu 29 Oct 87 12:08:43-PST
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Thu, 29 Oct 87 12:10:07 PST
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Thu, 29 Oct 87 12:58:33 mst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Thu, 29 Oct 87 12:57:42 mst
Received: from hpfcdcm by hpfcdcm.HP.COM; Thu, 29 Oct 87 12:57:30 mst
Return-Path: <dcm@hpfcdcm>
To: x3j13@sail.stanford.edu
Cc: mathis@ada20.isi.edu, dcm%hpfcdcm@hplabs.HP.COM
Subject: November X3J13 meeting
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Thu, 29 Oct 87 12:57:27 MST
Message-Id: <5124.562535847@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
Last call for reservations and registrations. Please send me a
registration form in addition to making your reservations. I need to give
a tentative head count to the the hotel and the restaurant next Monday,
November 2, with final counts due the following Monday, November 9. So far
I've heard from the following people:
Kathy Chapman Digital Equipment Corporation
Walter van Roggen Digital Equipment Corporation
Dan Pierson Encore Computer Corporation
Sandra Loosemore Evans & Sutherland Computer Corp.
Steve Haflich Franz Inc.
Kevin Layer Franz Inc.
James Kempf Hewlett Packard Company
Dave Matthews Hewlett Packard Company
George Hadden Honeywell
Aaron Larson Honeywell
Thom Linden IBM
Mary Van Deusen IBM
Dick Gabriel Lucid, Inc.
JonL White Lucid, Inc.
Linda DeMichiel Lucid, Inc.
Christopher Dabrowski National Bureau of Standards
Chris Perdue Sun Microsystems
Sonya Keene Symbolics, Inc.
David Moon Symbolics, Inc.
David Bartley Texas Instruments
Patrick Dussud Texas Instruments
Daniel Bobrow Xerox Corporation
Pavel Curtis Xerox Corporation
Gregor Kiczales Xerox Corporation
Larry Masinter Xerox Corporation
The dinner selections thus far seem to favor duck, shrimp, chicken, and
lamb using a simple first choice heuristic.
First choice Second Choice
Shrimp XXXX XXXX
Lamb XXXX XXXXX
Sirloin XX XXXX
Duck XXXXX XX
Salmon XX XXXXX
Chicken XXX X
Veg. X
A few ski resorts have already opened, Jeff Rosenking is looking for other
skiers to join him on a trip the weekend before the meeting. Your ski
reservations, including lift tickets, can also be made through Lifeco
travel when you make your travel reservations.
There are some small board rooms available at the hotel if you would like
to use them Monday for committee meetings. Please let me know what times
you would like to reserve one so I can have one set aside for you.
By the way, I seem to have typoed my phone number in the last mailing. The
correct phone number is (303)229-2201.
Dave Matthews
--------------------------------------------------------------------------
X3J13 Meeting
11/16/87 - 11/18/87
Fort Collins, Colorado
The fifth meeting of X3J13 will be held Monday through Wednesday, November
16-18 at the University Park Holiday Inn in Fort Collins, Colorado. Monday
has been set aside for committee meetings, followed by the main meeting on
Tuesday and Wednesday. November is the perfect time to see fall (and
sometimes winter) in Colorado. Rocky Mountain National Park is
approximately one hour from Fort Collins.
Hewlett-Packard's travel affiliate, Lifeco Travel, has negotiated discount
airfares that you can obtain by calling:
800-521-8858 (in California)
800-722-8755 (elsewhere)
Ask to make a group reservation for X3J13. You may also make your room,
rental car, or airport limousine reservations through Lifeco at the same
time. Payment must be made by credit card. Tickets will be mailed via
registered mail. Late reservations can be express mailed at additional
cost.
A block of rooms is available at the University Park Holiday Inn at $46.50
plus tax per night. If you don't make reservations through Lifeco Travel,
please make your own reservations by calling (303)482-2626 and asking to
reserve a room in the "HP X3J13" block. Reservations will be held until 6
PM unless guaranteed by a major credit card. Non-smoking rooms are
available. Check-in and check-out times are 1 PM. The block of rooms will
be dropped on 11/2/87, but you should still be able to obtain the
discounted room rate on available rooms if you specify you are attending
the the "HP X3J13" conference.
Refreshments and lunch are being arranged for Tuesday and Wednesday. I
expect these arrangements will run $50 per person which I will collect at
the meeting. Please note any dietary restrictions so I can make the
necessary arrangements with the catering department.
If there is sufficient interest I would like to arrange a dinner Tuesday
evening at Cuisine, Cuisine. Cuisine, Cuisine is an intimate cafe offering
some the best and most unusual food in Northern Colorado. It is a very
small cafe which can only accommodate 60 total patrons, but they are
willing to put together a special banquet for us. To handle a group this
large in a short period of time they would like to limit the menu to 4
items. The list of possible entrees includes: Cajun roast duckling with
spice peach gravy, chicken boursin (double breast of chicken stuffed with
herbed cream cheese dressing and mushroom voloute' sauce), shrimp diane
(sauteed jumbo shrimp in a garlic cajun sauce), sirloin tips with mushrooms
and onions, poached salmon with a special sauce, or boned leg of lamb
stuffed with spinach and served with a dijon sauce. A vegetarian entree
will also be available. Entrees would be about 15 dollars, including soup
or salad. Appetizers, dessert, and beverage would be ala carte. Cuisine,
Cuisine accepts charge cards, but cash would also be welcome.
I would need to narrow this to the four items at least 2 weeks in advance
so they could make the necessary preparations. Note if you are interested
on the registration form and mark your first and second choice entrees.
Please note any dietary restrictions if this selection is not sufficient.
Fort Collins is approximately a one hour drive from Denver's Stapleton
International Airport. From the airport take I-270 or I-70 west to I-25
and go north on I-25 towards Cheyenne, Wyoming. Take the first Fort
Collins exit, #265, turn left and drive 5 miles to the College Avenue
intersection. Turn right and drive 3 miles to the Prospect Road
intersection. Turn left and the Holiday Inn is just across the railroad
tracks on the south side of the road. It shouldn't be hard to see since it
is 8 stories tall in an area with very few building over 2 stories.
Two limousine services provide shuttle service from Stapleton directly to
the Holiday Inn. Fort Collins Express (303-482-0505) leaves Stapleton on
the hour while the Front Range Airporter (303-221-5466) leaves Stapleton on
the half hour. Both are located in the baggage claim area. The charge is
$12 each way on the Express and $13 on the Airporter.
| Prospect Road ||
=========|====================== ||
HI | ||
M | ||
O | ||
U | ||
N | Drake Road North ||
T =========|====================== /\ ||
A | || ||
I |US 287/ College Avenue ||
N | ||I-25
S | ||
| Horsetooth Road ||
=========|====================== ||
| ||
| ||
| ||
| ||
| Harmony Road HP /||\
=========|=============================================||===========
| \||/ Exit 265
| ||
||
\/
Denver
Please return the following registration form by November 2 via electronic
mail to dcm%hpfclp@hplabs.hp.com or via US Mail to:
Dave Matthews
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado 80525
(303)229-2201
Feel free to contact me if you have any questions.
__________________________________________________________________________
X3J13 NOVEMBER MEETING REGISTRATION FORM
Name: __________________________________________________
Institution: __________________________________________________
Street Address: __________________________________________________
City, State, Zip: __________________________________________________
Phone: __________________________________________________
Network Address: __________________________________________________
Dinner 11/17 (y/n): __________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂11-Nov-87 1800 X3J13-mailer Final reservations
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 87 17:13:02 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Wed 11 Nov 87 17:08:57-PST
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Wed, 11 Nov 87 17:12:18 PST
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Wed, 11 Nov 87 17:58:16 mst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Wed, 11 Nov 87 17:57:42 mst
Received: from hpfcdcm by hpfcdcm.HP.COM; Wed, 11 Nov 87 17:57:43 mst
Return-Path: <dcm@hpfcdcm>
To: x3j13@sail.stanford.edu
Cc: mathis@ADA20.ISI.EDU
Subject: Final reservations
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Wed, 11 Nov 87 17:57:40 MST
Message-Id: <1830.563677060@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
I've scheduled two conference rooms for Monday afternoon for
subcommittee meetings - one for the cleanup committee and one for
the character committee. They will be available all afternoon.
This is the latest list of registrants and dinner guests that I
have. If you aren't listed, such as Bob Mathis, and plan to
attend, please give me a call.
I've eliminated the chicken and salmon as a result of low demand
and added a new dinner choice column to the list of registrants.
Please call me if you have ????? for your dinner selection as you
will need to choose something else.
If you have any questions or need additional help call me and
leave a detailed message if I'm not available. I'll try to get
back to you ASAP.
Dave Matthews
303-229-2201
Peter Coffee Aerospace Corporation -
Jim O'Dell Alliant Computer sirloin
Kathy Chapman Digital Equipment Corporation veg
Walter van Roggen Digital Equipment Corporation duck
Dan Pierson Encore Computer Corporation duck
Sandra Loosemore Evans & Sutherland Computer Corp. shrimp
Steve Haflich Franz Inc. ??????
Kevin Layer Franz Inc. sirloin
Richard Greenblat GigaMOS Systems, Inc. sirloin
Jeff Rosenking Grumman Corporation shrimp
Paul Beiser Hewlett Packard Company shrimp
James Kempf Hewlett Packard Company duck
Dave Matthews Hewlett Packard Company lamb
George Hadden Honeywell shrimp
Aaron Larson Honeywell shrimp
Thom Linden IBM shrimp
Mary Van Deusen IBM duck
Greg Nuyens ILOG S.A. duck
Jerome Chailloux INRIA/ILOG duck
Mary Boelk Johnson Controls, Inc. shrimp
Dick Gabriel Lucid, Inc. sirloin
JonL White Lucid, Inc. lamb
Jan Zubkoff Lucid, Inc. duck
Linda DeMichiel Lucid, Inc. lamb
David Loeffler MCC sirloin
Christopher Dabrowski National Bureau of Standards -
Eric Schoen Schlumberger Palo Alto Research -
Chris Perdue Sun Microsystems duck
Sonya Keene Symbolics, Inc. sirloin
Bob Kerns Symbolics, Inc. ??????
David Moon Symbolics, Inc. -
Kent Pitman Symbolics, Inc. duck
Will Clinger Tektronix Laboratories -
David Bartley Texas Instruments lamb
Patrick Dussud Texas Instruments -
Ellen Waldrum Texas Instruments shrimp
Guy Steele Thinking Machines Corporation shrimp
Thomas Turba Unisys Corp. shrimp
Julian Padget University of Bath duck
Jeff Dalton University of Edinburgh sirloin
Daniel Bobrow Xerox Corporation lamb
Pavel Curtis Xerox Corporation lamb
Andy Daniels Xerox Corporation lamb
Gregor Kiczales Xerox Corporation duck
Larry Masinter Xerox Corporation shrimp
∂12-Nov-87 1335 X3J13-mailer next meeting
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 13:34:57 PST
Date: 12 Nov 1987 16:18-EST
Sender: MATHIS@A.ISI.EDU
Subject: next meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]12-Nov-87 16:18:49.MATHIS>
I've talked to Dave Matthews. If there are any other remaining
reservations, please let him know.
The agenda will be committee reports and regular business on
Tuesday morning. Tuesday afternoon I think will be best spent on
more informal, but more in depth, discussions of the work of the
CLOS and clean-up committees. Wednesday will contain a
continuation of these discussions and also the formulation of a
ballot on clean-up issues (since they haven't been distributed in
advance we can't finalize the vote at the meeting, on the other
hand we may not be to the stage of having a formal mail ballot
either).
We also have to discuss our plans for a standard for Common Lisp
and our plans for the ISO work. There will also be reports from
the editorial, windows, characters, and other subcommittees.
The agenda is not full of a lot of little topics, but is oriented
toward reaching some general understanding of the issues
involved.
-- Bob
∂29-Nov-87 1424 X3J13-mailer subcommittees
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 29 Nov 87 14:24:00 PST
Date: 29 Nov 1987 17:22-EST
Sender: MATHIS@A.ISI.EDU
Subject: subcommittees
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]29-Nov-87 17:22:16.MATHIS>
here is my version of how the subcommittee evolved at the Ft. Collins
meeting. PLEASE send me any additions or other corrections.
If you have an electronic mailing list, please let me know and tell
me how people outside the subcommittee should be involved with that
list (if at all)
X3J13 Subcommittees (as of November 29, 1987
(Mathis, Steele, and Gabriel try to follow all)
Editorial:
Kathy Chapman, chair
Ron Ohlander
Mary Boelk
Dick Gabriel
Kent Pitman
Walter van Roggen
Skona Brittain
Character Subcommittee <cl-natural-languages
Thom Linden, chair (IBM Research)
Larry Masinter (XEROX Research)
Carl Hoffman (International Lisp Associates)
Bob Kerns (Symbolics)
Duncan Missimer (Hewlett-Packard)
Dave Matthews (Hewlett-Packard)
Mike Beckerle (Gold Hill)
Kevin Layer (Franz)
ISO/IEC JTC1/SC22/WG 16 Delegation:
Dick Gabriel, chair
Guy Steele
Bob Mathis
Patrick Dussud
Thom Linden
Larry Masinter
Will Clinger
Bill Scherlis
Kent Pitman
John McCarthy
Iteration
Jon L. White, chair
Pavel Curtis
Chris Purdue
Dan Weinreb
Errors and Conditions
Kent Pitman, chair
Andy Daniels
Validation and Conformance
--, chair
David Slater
Mike Beckerle
Chris Dambroski
Compiler Specification
Steve Haflich, chair
David Bartley
Mike Beckerle
Rob McLaughlin
Walter van Roggen
CLOS
Danny Bobrow, chair
David Moon
Dick Gabriel
Gregor Kiczales
Linda DeMichiel
Sonya Keene
Patrick Dussud
Jim Kempf
Lisp1/Lisp2
Dick Gabriel
Will Clinger
Kent Pitman
Mark Wegman
Richard Greenblat
Dan Weinreb
Macros
Mark Wegman
Julian Padget
Steve Haflich
Kent Pitman
Graphics and Windows
Erik Schoen, chair
George Haden
Ellen Waldrum
Types & Declarations
Bill Scherlis
Clean-up
Larry Masinter
Guy Steele
Kent Pitman
JonL White
Scott Fahlman
David Moon
Ellen Waldrum
Meeting Planning
Jan Zubkoff
∂02-Dec-87 1545 X3J13-mailer 11-87 minutes
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 15:44:53 PST
Received: by labrea.stanford.edu; Wed, 2 Dec 87 15:41:10 PST
Received: from sunvalleymall.lucid.com by edsel id AA11888g; Wed, 2 Dec 87 15:35:55 PST
Received: by sunvalleymall id AA08895g; Wed, 2 Dec 87 15:35:59 PST
Date: Wed, 2 Dec 87 15:35:59 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8712022335.AA08895@sunvalleymall.lucid.com>
To: x3J13@sail.stanford.edu
Subject: 11-87 minutes
Plans for March meeting to follow.
X3J13/87-038
Minutes
Ft. Collins, CO
11/17/87 - 11/18/87
Item 1: Call to Order, Bob Mathis
9:00 am - Tuesday, November 17, 1987. Ft. Collins meeting called to order.
Introductory remarks. Attendance list send around. Introduction of
attendees.
Item 4: Report on ISO Ballot (Doc: 87-031), Bob Mathis
Letter from Bob Mathis to Catherine Kachurick. Letter from Thomas Turba to
Bob Mathis. Letter from Catherine Kachurick to X3. Preliminary Draft of
ISO/IEC JTC 1 Information Technology Secretariat: USA (ANSI). Summary of
Voting Document. Proposed comments from US on the name for the resulting
ISO standard on LISP. Draft UK Position on LISP.
Item 2: Approval of Agenda, Bob Mathis
Proposed agenda (X3J13/87-037) approved with minor changes. No windows and
a shorter CLOS discussion.
Item 5: Other administrative matters, Bob Mathis
New document register is available. List of subcommittees (please send
Mathis changes of members and send electronic mailing address). X3 bills
have been sent out. Make checks for this meeting payable to Hewlett Packard
and give to Dave Matthews during break. Dinner will be at 6:30pm.
Item 8: Characters, Thom Linden Committee name and scope. Name change
Natural Language Committee to Character Committee. JEIDA acknowledgement
and interaction network. IBM proposal. Thom will have a detailed proposal
at the March meeting. Committee will discuss one topic at a time. Bob
Mathis will forward ISO character notes to Thom Linden.
Item 9: Iteration, JonL White
Work promised on MIT LOOP at Cambridge meeting has just begun. Discussion
on whether standard is needed for portable loops. Discussion on why loop
and do standards may be necessary for new programmers.
Item 10: Lisp1/Lisp2, Common Lisp and Scheme, Will Clinger
Discussion on denotational semantics. Should we dissolve the Lisp1/Lisp2
committee? Should we broaden the committee to look at semantics of the
entire language? We need to take a vote.
11:30am - Morning Break
Item 12: Reports from other subcommittees
Errors, Kent Pitman
No new revisions. Will send mail with questions posed since last meeting.
Will have proposal for approval at next meeting.
12:00 - Lunch
Item 11: Editorial, Kathy Chapman
Discussed whether spec should be CLtL with changes or start from scratch.
Presented idea of 2 manuals, one a formal spec and one a rationale manual.
We need to decide what the deadline for the manual is.
2:30 pm - Break
Item 12: Reports from other subcommittees
Macros, Julian Padget
Brief overview. Please send examples of hairy macros to Julian Padget. A
brief summary will be available at next meeting.
Item 12: Reports from other subcommittees
CLOS, Gregor Kiczales
Committee has filled in chapters 1 and 2. Chapter 3 will be decided in
December at a Meta Objects meeting in Boston. Changes include: loosened
lambda-list congruence rules, instance creation and initialization,
simplified with-slots, handling some exception conditions, and lexical
generic functions. Next revision will be available in February 1988.
Please send comments via net-mail by end of February so changes can be made
by the March meeting.
Item 12: Reports from other subcommittees
Validation, Bob Mathis
Rich Berman has left ISI. This leaves the validation committee unmanned.
Item 12: Reports from other subcommittees
Type and Declaration, Bob Mathis
Bill Scherlis was to report. Nothing has been reported.
4:15pm - Break
4:25pm - Bob Mathis proposed the agenda for Wednesday's meeting be 9:00 -
10:30 Cleanup Committee, wrapping up by lunch and have committee meetings
after lunch.
Item 14: Extended Discussion on CLOS and Clean-up, Larry Mascinter
General remarks and review issue status. Intent is writing for editor the
go-ahead on issues. Ran quickly through issues.
Item 15: Recess, 4:55pm
Item 16: Call to Order, November 18, 8:59am, Bob Mathis
Item 17: Further discussions on cleanup and drafting, Larry Mascinter
The following people contributed issues and discussions but are not on the
clean-up committee. We thank them for their participation.
Dan Carnese Schlumberger
Will Clinger Tektronics
Pavel Curtis Xerox
Steve Haflich Franz
Dieter Kolb Siemans
Sandra Loosemore E&S/Utah
Rob McLaughlin CMU
Jeff Peck SUN
Jonathan Rees MIT
Dave Touretzky CMU
Discussed "need volunteer" issues. Bob Mathis will mail a ballot on closed
topics from clean-up committee. JonL White proposed we bring forward old
issues and reject or adopt them. Larry Mascinter will provide a list.
AREF-1D no comments or objections
GET-SETF-METHOD-ENVIRONMENT no comments or objections
KEYWORD-ARGUMENT-NAME-PACKAGE no comments or objections
PATHNAME-STREAM some comments no objections
DO-SYMBOLS Jonl White suggested DO-PRESENT-SYMBOLS
and will send mail to Larry Masinter.
DECLARE-MACROS Goldhill objected on grounds of incompatible
changes. A long discussion ensued.
10:38am - Break
Item 17: Further discussions on cleanup and drafting, continued.
PATHNAME-SUBDIRECTORY-LIST
Item 22, 24: Planning Relative to Other Technical Issues,
Review Action Item Assignments, Bob Mathis
ISO letter. Committee chairman, people on committees, net names. A motion
was made to thank Lucid, Goldhill and Hewlet Packard. The motion was
approved and Bob Mathis will send thank you letters.
Item 23: Future Meetings, Bob Mathis
Discussion of length and format of future meetings. It was voted that we
would have a 5 day meeting in March 1988 and a tentative date was set for
March 21 through March 25. The first 2 days will be set aside for
subcommittee meetings, the next 2 days will be used for the meeting, and the
last day will be set aside for subcommittee meetings. A reminder that all
proposals should be in the hands of the committee 2 weeks prior to the
meeting. That means mailing 4 - 5 weeks before the actual meeting.
The following meetings are tentatively scheduled June 13 - 17 on the east
coast, September 26 - 30 central or west coast and January 9 - 13 1989 in
Hawaii.
(NOTE: Although March 21 - 25 was discussed as a possible meeting date,
March 14 - 18 has really been set. )
Item 20: Planning for ISO participation, Bob Mathis
Discussion on who should/could go to ISO in February.
Item 25: Adjournment 12:00, Bob Mathis
Jan Zubkoff
Acting Sectretary
∂14-Dec-87 1055 X3J13-mailer March meeting
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Dec 87 10:55:42 PST
Received: by labrea.stanford.edu; Mon, 14 Dec 87 10:44:55 PST
Received: from sunvalleymall.lucid.com by edsel id AA06718g; Mon, 14 Dec 87 10:19:51 PST
Received: by sunvalleymall id AA10259g; Mon, 14 Dec 87 10:20:42 PST
Date: Mon, 14 Dec 87 10:20:42 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8712141820.AA10259@sunvalleymall.lucid.com>
To: labrea!x3j13%sail.stanford.edu@labrea.stanford.edu
Subject: March meeting
X3J13
3/14/88 - 3/18/88
Palo Alto, CA
The next meeting of X3J13 will be held from 9:00am, Wednesday, March 16,
1988 until 5:00pm, Thursday, March 17, 1988, at the Hyatt Rickeys in Palo
Alto, CA. The meeting will be held in the Executive Conference Room.
Subcommittee meetings will be held Monday, March 14, Tuesday, March 15 and
Friday, March 18.
Please let me know if and when your subcommittee will be meeting in Palo
Alto in March. I need to reserve small rooms now if they're necessary. In
the interest of saving money, if you have a subcommittee member who is local
perhaps the meeting could be held at their company.
For example: the CLOS subcommittee will meet at Lucid
Monday, 3/14 and Tuesday 3/15 at 10:00. Friday's time is
yet to be determined.
A block of rooms is available at the Hyatt Rickeys. The rate will be $84 a
night (plus tax). A limited number of rooms are available for non-smokers.
Please call (800) 228-9000 or (415) 493-8000 before February 26 to receive
the discounted rate. Be sure to mention "X3J13 Standards Committee".
Thank you Dave Matthew for letting us use the HP discount!
Before I call and get special airline fares I'd like to know if anyone has
found this to be useful. If I get no replies I'll assume it's not necessary
to set up special fares.
Refreshments will be available during the morning (8:00am) and afternoon
sessions. Lunch will be available Wednesday, March 16 and Thursday, March
17. If you have dietary restrictions please complete the appropriate
section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
I will be happy to arrange a group dinner for Wednesday, March 16. Someone
has suggested we go to Watercourse Way in Palo Alto for sushi dinner and go
hot tubbing afterwards at (combined fee of around $25) If interested, please
note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
|X Hyatt Rickeys |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
San Jose Airport
!
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rush hour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-0800. Hertz, Avis and National car rentals are
within 1 block.
Directions from San Jose airport: Take 101 north to San Antonio Road (about
15 minutes in non-rushhour traffic). Take San Antonio Road exit marked Los
Altos, heading toward the hills. Turn right on El Camino Real. The hotel
is on the right at 4219 El Camino Real, Palo Alto, CA 94306 (415) 493-0800.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@labrea.stanford.edu
(415) 329-8400
!
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
!
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Lunch 3/18: yes _______ no _______
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Sushi Dinner 3/16: yes ______ something else ______
Hot tubbing 3/16: yes ______ something else ______
Set up special airline fares: yes _______ no _______
Subcommittee Name: _________________________________________________
Subcommittee Chair: ________________________________________________
____ We need a meeting room
____ We will be meeting at _________________________________________
∂11-Jan-88 1056 X3J13-mailer mailings
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Jan 88 10:55:54 PST
Received: by labrea.stanford.edu; Mon, 11 Jan 88 10:56:00 PST
Received: from sunvalleymall.lucid.com by edsel id AA19685g; Mon, 11 Jan 88 10:49:25 PST
Received: by sunvalleymall id AA28780g; Mon, 11 Jan 88 10:52:13 PST
Date: Mon, 11 Jan 88 10:52:13 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8801111852.AA28780@sunvalleymall.lucid.com>
To: x3J13@sail.stanford.edu
Cc: edsel!jlz@labrea.stanford.edu
Subject: mailings
This is a reminder that any subcommittee papers need to be mailed
by Friday 2/5 in order to reack committee members in time.
That's only 3 weeks from Friday folks...
---jan---
∂11-Jan-88 1249 X3J13-mailer mailings
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 11 Jan 88 12:49:36 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Mon, 11 Jan 88 15:49:30 EST
Received: by kali.think.com; Mon, 11 Jan 88 15:49:26 EST
Date: Mon, 11 Jan 88 15:49:26 EST
From: gls@Think.COM
Message-Id: <8801112049.AA11904@kali.think.com>
To: x3J13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 11 Jan 88 10:52:13 PST <8801111852.AA28780@sunvalleymall.lucid.com>
Subject: mailings
I would like to appeal to all subcommittees to try very hard to submit
material for mailing to X3J13 members as Jan has requested. Failure to
use this mailing-out mechanism slows our progress by a factor of two!
(To see why, consider that a proposal based on feedback from the December
meeting can be voted on in March if mailed out ahead, but cannot be voted
on until June if first presented at the March meeting.)
We stand a very good chance of having a draft ready for public review by
December 1988 or maybe March 1989, *provided* that we make good use of time
by mailing proposals out ahead of meetings. Here is a plausible schedule,
if also an optimistic one:
February: Mail out current CLOS draft.
Mail out current error proposal draft.
Mail out cleanup proposals so far.
Mail out other proposals (character sets? iteration?).
March: Vote on all this stuff. Probably CLOS needs two more
iterations and error proposal needs one more iteration.
Some small fraction of cleanup proposals require iteration.
May: Mail out CLOS draft N-1.
Mail out error proposal draft M.
Mail out more cleanup proposals.
Last chance to mail other proposals without blowing the schedule.
Mail out whatever draft manual the editorial committee has so far.
June: Vote on CLOS draft; probably needs one more round.
Vote on error draft; with any luck this is final or
requires only very minor tweaking.
Vote on more cleanup proposals.
Vote on other proposals. Probably more work needed.
Provide feedback to editorial committee (now and by mail later).
August: Mail out CLOS draft N.
Mail out more cleanup proposals (the last ones???).
Mail out draft standard.
September: Vote on CLOS draft. With any luck this is final. (If we cannot
get a final vote by now, I despair of ever having one.)
Vote on cleanup proposals.
Vote on other proposals.
Provide lots of feedback to editorial committee.
November: Mail out reasonably final draft standard.
December: Vote on draft standard. Either it is ready for public review
or it isn't. (It need not be absolutely perfect, but should
be in good shape.) If it isn't, then another vote in March
is needed.
Such a schedule will demand hard work by the subcommittees, especially the
CLOS, cleanup, and editorial committees. I do know that Larry Masinter has
been working hard on the cleanup proposals, and the CLOS group met in
mid-December. Everyone else should only work so hard. If we do not have
the ambition to try for a schedule like this, then we are looking at a
public review in 1990 or beyond, at our present rate, and a standard
perhaps not until 1992. We need it much sooner than that.
Let's get cracking.
--Guy
∂26-Jan-88 1107 X3J13-mailer voting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 11:07:26 PST
Date: 26 Jan 1988 14:06-EST
Sender: MATHIS@A.ISI.EDU
Subject: voting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]26-Jan-88 14:06:48.MATHIS>
At the upcoming meeting (March 14-18, including subcommittees)
in Palo Alto, I expect that we may be voting on some things.
After reviewing the attendance records of the last two meetings,
the following members representatives will be eligible
to vote (assuming they have also paid their X3 service fee).
If there are any questions or corrections, please contact me
as soon as possible.
-- Bob
Company Name Cambridge
====================================
Ft. Collins
A.I. Architechs X
Aerospace X
Alliant X
Bath, U. X X
CSC X
DEC X X
Edinburgh, U. X X
Encore X
Evans & Southerland X
Franz X X
Gensym X
Gigamos X X
GMD X
Goldhill X X
Gould X
Grumman X X
Hewlett Packard X X
Honeywell X X
IBM X X
ILOG S.A. X
INRIA X
Internat. Lisp Assoc. X
Johnson Controls X X
Lucid X X
Mathis X X
MCC X X
Micro. Sys. Consults. X
MIT X
Mitre X X
NBS X
Prime X
Red Shark Software X
Schlumberger X
Sun X
Symbolics X X
Tectronix X X
Texas Instruments X X
Thinking Machines X X
Unisys X X
USC-ISI X
Wang X
Xerox X X
∂01-Feb-88 1511 X3J13-mailer Don't forget mailings
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 15:11:15 PST
Received: by labrea.Stanford.EDU; Mon, 1 Feb 88 15:11:29 PST
Received: from sunvalleymall.lucid.com by edsel id AA13089g; Mon, 1 Feb 88 14:55:21 PST
Received: by sunvalleymall id AA09790g; Mon, 1 Feb 88 14:59:40 PST
Date: Mon, 1 Feb 88 14:59:40 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802012259.AA09790@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: Don't forget mailings
Documents for X3J13 should be mailed this week in order to reach
committee members on time. If you need mailing lables please
contact Bob Mathis.
---jan---
∂13-Feb-88 1728 X3J13-mailer Issues from the cleanup sub-committee
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:28:50 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:29:36 PST
Date: 13 Feb 88 17:29 PST
From: Masinter.pa@Xerox.COM
Subject: Issues from the cleanup sub-committee
To: X3J13@Sail.stanford.edu
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880213-172936-10523@Xerox>
The cleanup committee has a number of issues for discussion and/or voting at the
next X3J13 meeting. I will be mailing out those issues which are ready for
voting at the next meeting, one at a time.
I am uncertain as to the exact procedure for voting; I imagine that Bob Mathis
will help clarify. My current understanding is that you should be prepared
either to vote for endorsing a proposal or should prepare a written objection.
Please address your replies directly to cl-cleanup@Sail.stanford.edu. We promise
to summarize and redistribute any replies we get. X3J13@Sail.stanford.edu should
*not* be used for technical discussions, however.
The cleanup issues fall into several categories.
Passed X3J13/Jun87:
Mailed to X3J13 prior to the June 1987 meeting of X3J13 and passed (via voice
vote) at that meeting.
As these were distributed before, they will not be mailed again except by
individual request, although the issues will appear on the ballot.
Conditionally passed X3J13/Jun87, new version passed X3J13/Nov87:
While an earlier version was mailed to X3J13 prior to the Jun87 meeting, the
most recent version was distributed only in hardcopy at the November 1987
meeting.
Passed X3J13/Nov87:
Distributed only via hardcopy at the November 1987 meeting.
New ballot items for Mar88:
Not previously distributed to X3J13, but ready for voting.
In discussion:
Some of these issues may be distributed via electronic mail to X3J13 prior to
the March meeting for discussion at the meeting, although they will not appear
on a ballot at that time.
∂14-Feb-88 1045 X3J13-mailer Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 10:45:27 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 10:45:59 PST
Date: 14 Feb 88 10:45 PST
From: Masinter.pa@Xerox.COM
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-104559-1224@Xerox>
This issue has not been distributed to X3J13 before.
!
Issue: ADJUST-ARRAY-DISPLACEMENT
Reference: ADJUST-ARRAY (CLtL p.297)
Category: Clarification
Edit history: Version 1 by Fahlman, 18-Apr-87 (from Steele's list)
Version 2 by Masinter
Version 3 by Masinter, 5-Jun-87 (respond to comments)
Version 4 by Masinter, 23-Nov-87
Problem Description:
The interaction of ADJUST-ARRAY and displaced arrays is insufficiently specified
in the case where the array being adjusted is displaced.
Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES
Interaction of adjusting and displacement:
Suppose we are adjusting array A, which is perhaps displaced to B before the
ADJUST-ARRAY call and perhaps to C after the call.
(1) A is not displaced before or after: The dimensions of A are altered, and the
contents rearranged as appropriate. Additional elements of A are taken from the
:INITIAL-ELEMENT. The use of :INITIAL-CONTENTS causes all old contents to be
discarded.
(2) A is not displaced before, but is displaced to C after. As specified in
CLtL, none of the original contents of A appears in A afterwards; A now contains
the contents of C, without any rearrangement of C.
(3) A is displaced to B before the call, and is displaced to C after the call.
(B and C may be the same.) As in case (2), the contents of B do not appear in A
afterward (unless such contents also happen to be in C). If
:DISPLACED-INDEX-OFFSET is not specified in the ADJUST-ARRAY call, it defaults
to zero; the old offset (into B) is not retained.
(4) A is displaced to B before the call, but not displaced afterward. A gets a
new "data region", and contents of B are copied into it as appropriate to
maintain the existing old contents; additional elements of A are taken from the
:INITIAL-ELEMENT. However, the use of :INITIAL-CONTENTS causes all old contents
to be discarded.
If array X is displaced to array Y, and array Y is displaced to array Z, and
array Y is altered by ADJUST-ARRAY, array X must now refer to the adjusted
contents of Y. This means that an implementation may not collapse the chain to
make X refer to Z directly and forget that the chain of reference passes through
array Y. (Cacheing techniques are of course permitted, as long as they preserve
the semantics specified here and in CLtL.)
If X is displaced to Y, it is an error to adjust Y in such a way that it no
longer has enough elements to satisfy X. This error may be signalled at the
time of the adjustment, but this is not required.
Note: Omitting the :DISPLACED-TO argument to ADJUST-ARRAY is equivalent to
specifying :DISPLACED-TO NIL; in either case, the array is not displaced after
the call and case (1) or (4) hold.
Rationale:
This interaction must be clarified. This set of rules was proposed some time
ago, as a result of discussions on the Common Lisp mailing list, and this model
has been adopted by many Common Lisp implementations.
Current Practice:
Many implementations currently follow the model proposed here, although they
differ in some detail. For example, Symbolics Common Lisp behaves as indicated
except for case (4); in that case, it never copies the contents of B, and all
elements are taken from the :INITIAL-ELEMENT.
Cost to implementors:
Some existing implementations may have to be changed, but adopting any other
model would be worse. Public-domain code implementing this model is available
from CMU.
Cost to users:
This is a relatively uncommon situation, which is the reason it didn't occur to
the original language designers to specify how it works. Any user code that
cares about this issue probably already follows the proposed model.
Benefits:
Clarification of a situation that is currently not addressed by the standard.
Discussion:
The cleanup committee supports this clarification.
Some consideration was given to adding DISPLACED-ARRAY-P or ARRAY-DISPLACED-TO
and ARRAY-DISPLACED-INDEX-OFFSET which would allow access to information as to
whether an array was or was not displaced. However, these are not part of the
current proposal.
A similar issue arises with ADJUST-ARRAY and fill pointers, and will be the
subject of a separate issue.
∂14-Feb-88 1049 X3J13-mailer Issue: APPEND-DOTTED (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 10:49:35 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 10:50:04 PST
Date: 14 Feb 88 10:49 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: APPEND-DOTTED (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-105004-1227@Xerox>
This issue was distributed in hardcopy at the November 1987 meeting of X3J13.
!
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
14-Jan-88, Version 5 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of what
happens if an argument to APPEND is a dotted list. The only case explicitly
mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be any LISP
object, which becomes the tail end of the constructed list. For example, (append
'(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is not a
list, the behavior when any of the other arguments are not lists is not
specified.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the list to be
returned.
In the degenerate case where there is no last cons (i.e., the argument is NIL)
in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument is a
non-list, the result of APPEND or NCONC can be a non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are the
same, since these two might legitimately differ in situations involving dotted
lists. As such, deciding which to use is not just a stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number of
implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter). Franz's Allegro Common Lisp
conforms to the proposed behavior except in the case of (NCONC (LIST) 17) => 17,
where it returns NIL instead of 17.
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted list.
Xerox Common Lisp signals an error on APPEND and implements the proposed
interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those implementations
which don't already implement it. However, implementations which have microcoded
APPEND or NCONC incompatibly may find the small change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect only NIL
when SAFETY is 0. In this case, depending on implementation details, requiring
an ATOM check rather than a NULL check may slow things down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and NCONC can
therefore produce dotted lists, some readers may have (incorrectly) assumed that
APPEND and NCONC can reliably deal in general with dotted lists, something that
doesn't appear to be guaranteed by a strict reading. The proposed extension
would happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the language
will depend largely on how they view the relation between lists and dotted
lists. Those who view dotted lists as a special kind of list may feel
differently than those who view lists as a special kind of dotted list.
Discussion:
The cleanup committee supports this proposal.
∂14-Feb-88 1057 X3J13-mailer Issue: AREF-1D (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 10:57:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 10:57:51 PST
Date: 14 Feb 88 10:57 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: AREF-1D (Version 7)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-105751-1238@Xerox>
This issue passed conditionally at the June 1987 meeting of X3J13. This version,
distributed in hardcopy at the November 1987 meeting, clarified some of the
details of the proposal.
!
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
02-Jun-87, Version 2 by Pitman (ROW-MAJOR-AREF)
6-Jun-87, Versions 3, 4 by Masinter (editorial)
11-Jun-87, Version 5, to X3J13 (no changes)
6-Jul-87, Version 6, by Masinter
14-Nov-87, Version 7, by Masinter (update discussion)
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY efficiently
in Common Lisp because they take arguments of varying rank. Currently, you have
to make a displaced array to work with temporarily and then throw away the
displaced array when you're done. In many cases, this is bothersome because
there is no a priori reason why they should have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF that allows one-dimensional access to
the storage backing up a given array assuming the normal row-major storage
layout.
ROW-MAJOR-AREF is valid for use with SETF.
row-major-aref array index [Function]
This accesses and returns the element of array specified by index when the
elements of array are considered in row-major order. Array may be an array of
any dimensionality. row-major-aref may be used with setf. For reference, the
following sets of expressions are equivalent:
(row-major-aref array index) ==
(aref (make-array (array-total-size array)
:displaced-to array
:element-type (array-element-type array))
index)
and
(aref array .. subscripts ..) ==
(row-major-aref array (array-row-major-index array .. subscripts ..))
Rationale:
Common Lisp requires row-major storage layout of arrays and has a number of
operators that allow users to exploit that order. ROW-MAJOR-AREF is a useful,
simple addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by loops that
had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this would involve something
like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations that already use this
primitive internally, it's little more than a matter of changing the name of or
otherwise releasing the existing primitive. In some implementations, it might
involve writing a small amount of code or compiler work to make ROW-MAJOR-AREF
work efficiently.
Benefits:
This gives users efficient access to something to which they already have
inefficient access.
Conversion Cost:
This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely to be
used by any current program.
Aesthetics:
This allows certain programs to be written in a more aesthetic way.
Discussion:
This issue was conditionally passed at X3J13/June 1987, pending clarification of
some details. Those clarifications have been made in this version.
∂14-Feb-88 1103 X3J13-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:03:09 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:03:31 PST
Date: 14 Feb 88 11:03 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: ASSOC-RASSOC-IF-KEY (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-110331-1248@Xerox>
This issue is new.
!
Issue: ASSOC-RASSOC-IF-KEY
References: ASSOC-IF (p280), ASSOC-IF-NOT (p280), RASSOC-IF (p281),
RASSOC-IF-NOT (p281)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
20-Nov-87, Versions 2,3 by Masinter
23-Nov-87, Version 4 by Masinter
Problem Description:
The descriptions of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT do not
mention a :KEY option, although ASSOC and RASSOC have one.
This is often reported as an inconsistency in Common Lisp.
Proposal (ASSOC-RASSOC-IF-KEY:YES):
Allow a :KEY keyword for ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT.
If not supplied, it should default to #'IDENTITY as do the :KEY keywords for
other -IF and -IF-NOT functions. The function, as with the :KEY argument for
ASSOC and RASSOC, is applied to the CAR of the pair in the association list for
ASSOC-IF and ASSOC-IF-NOT and the CDR of the pair for RASSOC-IF and
RASSOC-IF-NOT.
Documentation impact:
A better description of the intent might be to say that the car /contains/ the
key of the association, and by default the car /is/ the key of the association.
Example:
(assoc-if #'zerop pathnames :key #'pathname-version)
could be used to search a list indexed by pathnames finding one with zero
version.
Rationale:
This is an inconsistency in the language that is simple to fix.
Current Practice:
Symbolics implements :KEY for the -IF and -IF-NOT assoc functions. Others follow
the book and allow :KEY only for ASSOC.
Cost to Common Lisp implementors:
A small amount of additional code is necessary to support this in
implementations not already offering it as an extension.
Cost to Common Lisp users:
The change is essentially upward compatible with user code.
Benefits:
This would make the set of -IF and -IF-NOT functions be more regular in their
calling conventions.
Aesthetics:
All the other -IF and -IF-NOT variations of list operations omit the :TEST and
:TEST-NOT keywords, but allow :KEY. For example, consider the family of MEMBER,
MEMBER-IF, and MEMBER-IF-NOT. Although this introduces additional mechanism, it
does so in a way that probably makes it easier to think about which functions do
what, so it would likely be seen as a simplification.
Discussion:
The omission of :KEY in this situation in CLtL was probably an oversight.
The cleanup committee supports this proposal.
∂14-Feb-88 1109 X3J13-mailer Issue: COLON-NUMBER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:08:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:08:44 PST
Date: 14 Feb 88 11:08 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: COLON-NUMBER (Version 1)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-110844-1256@Xerox>
This issue was distributed in hardcopy at the November 1987 meeting of X3J13.
!
Issue: COLON-NUMBER
References: Parsing of Numbers and Symbols (p339-341, 343-344)
Category: CLARIFICATION
Edit history: 22-Oct-87, Version 1 by Pitman
Problem Description:
CLtL is unclear about whether a colon followed by a potential number is a
potential number. There are passages which seem to address this issue
unambiguously but fail.
Proposal (COLON-NUMBER:UNDEFINED):
Clarify that syntax involving a leading colon followed by a potential number is
not well-defined. That is, use of notation such as :1, :1/2, and :2↑3 in a
position where an expression appropriate for READ is expected is an error.
Rationale:
This makes the status quo apparent.
Current Practice:
Some implementations, such as Symbolics Lisp, claim the right to interpret this
as an ``is an error'' situation where their upward-compatible extension is to
parse ``:1'' as the number 1 (incidentally, but uninterestingly, expressed in
the KEYWORD package).
Other implementations tokenize ``:1'' as a single token, identify it as a
symbol, and then parse it as :\1 would be parsed.
Cost to implementors:
None. This clarification forces no implementations to change.
Cost to users:
Slight. Some users may have mistakenly believed that this was an aspect of the
language that was guaranteed and may have written programs that exploited that
belief. Such incidences are probably very rare, however. Also, even in the few
cases where such code fortuitously worked, implementations are likely to
continue to support it so such code will probably continue to fortuitously work
in many of those rare situations.
Benefits:
Programmer expectations that any useful behavior can be portably relied upon in
this pathological case should be soundly trounced.
Aesthetics:
Arguably a slight improvement in visual aesthetics. What was already a pretty
marginal syntax is discouraged.
Discussion:
Pitman supports this clarification. He thinks this issue is not a big deal, but
it does crop up often enough to be a nuisance. It would be nice to have everyone
acknowledge a unified position, even if that only meant agreeing to disagree.
∂14-Feb-88 1112 X3J13-mailer Issue COMPILER-WARNING-BREAK (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:12:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:13:23 PST
Date: 14 Feb 88 11:13 PST
From: Masinter.pa@Xerox.COM
Subject: Issue COMPILER-WARNING-BREAK (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <880214-111323-1266@Xerox>
This issue has not been distributed to X3J13 before.
!
Issue: COMPILER-WARNING-BREAK
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/27/87
Version 2 by cleanup committee 15-Mar-87 14:25:03
Version 3 by Masinter 5-Jun-87
Version 4 by Masinter 23-Nov-87
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not say whether
*BREAK-ON-WARNINGS* affects warnings output by the compiler. If this is to be
allowed, it should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-BREAK:YES):
The definitions of COMPILE and COMPILE-FILE should state that these functions
are required to break on warnings if *BREAK-ON-WARNINGS* is true (just as if it
calls WARN).
Note: User interface commands provided by particular vendor implementations
which implicitly call COMPILE or COMPILE-FILE could bind *BREAK-ON-WARNINGS*
back to NIL if they felt it important to not break for some reason relating to
cultural compatibility. This would not interfere with the proposed new semantics
for the functions COMPILE and COMPILE-FILE.
Rationale:
*BREAK-ON-WARNINGS* is defined to cause the debugger to be entered when warnings
occur. If the compiler is permitted to warn (separate ballot item), the effect
of this variable on compiler warnings should be nailed down.
Current Practice:
Some compilers respect *BREAK-ON-WARNINGS* and others probably do not.
Adoption Cost:
Those compilers which do not use WARN directly but some other mechanism might
have to be edited, but it would not be a major change.
Conversion Cost:
Probably little or no user code would be affected by this change.
Benefits:
This would make the language definition more consistent by making it less
subject to special cases. Portable programs can be assured of consistent
behavior when dealing with the compiler.
Aesthetics:
Most users will probably perceive this change as a simplification because it
will allow the kind of warning that comes from WARN and the kind of warning that
comes from compilation to be conceptually grouped.
Discussion:
*BREAK-ON-WARNINGS* and the compiler are part of the environment rather than the
language.
We considered but rejected the notion of a separate
*COMPILER-BREAK-ON-WARNINGS*. It is possible that with the adoption of a
signal/error system that the *BREAK-ON-WARNINGS* mechanism could be replaced in
its entirity by a more structured signal/handler structure, making this proposal
moot.
∂14-Feb-88 1125 X3J13-mailer Issue: DEFVAR-DOCUMENTATION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:25:02 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:25:36 PST
Date: 14 Feb 88 11:25 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-DOCUMENTATION (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <880214-112536-1283@Xerox>
An earlier version of this issue was distributed at the November 1987 meeting.
!
Issue: DEFVAR-DOCUMENTATION
References: DEFVAR, DEFPARAMETER, DEFCONSTANT (pp68-9)
Category: CLARIFICATION
Edit history: 30-Jun-87, Version 1 by Pitman
23-Nov-87, Version 2 by Masinter
Problem Description:
CLtL is not explicit about whether the documentation part of DEFVAR,
DEFPARAMETER, and DEFCONSTANT special forms is evaluated.
Proposal (DEFVAR-DOCUMENTATION:UNEVALUATED):
Clarify that the documentation part of DEFVAR, DEFPARAMETER, and DEFCONSTANT
special forms is not evaluated. That is, it must be a literal string, not a form
which evaluates to a string.
Examples:
(DEFVAR *MY-VARIABLE* (CONSTRUCT-INITIAL-VALUE) "A documentation string") ; OK
(DEFVAR *MY-VARIABLE* (CONSTRUCT-INITIAL-VALUE) GENERIC-DOCUMENTATION-STRING) ;
would be an error
Rationale:
To ensure portability, implementations must agree on whether or not this
position is evaluated. Specifying that the position is unevaluated is the
conservative thing to suggest, and consistent with the (unevaluated)
documentation strings in DEFUN, DEFSTRUCT.
Current Practice:
Some implementations evaluate this position. Others do not.
Cost to implementors:
Implementations that did not already check might usefully add a check in the
macro expansion for DEFVAR, DEFPARAMETER and DEFCONSTANT to assert that the
DOCUMENTATION, if supplied, was a string. The change is likely trivial.
Cost to users:
Code which uses other than a literal string is not portable, so no portable
programs will be broken. Some non-portable programs which rely on a particular
vendor's interpretation would have to be rewritten. Automatic tools to detect
most offending cases could trivially be constructed. (We know of no current
uses.)
Benefits:
Code portability would be improved. Some programming environment tools might
assume that documentation strings were determinable without evaluation.
Aesthetics:
Slight improvement; this implies consistent treatment for documentation strings
in all defining forms.
Discussion:
We think this is a good idea.
∂14-Feb-88 1130 X3J13-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:30:43 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:31:18 PST
Date: 14 Feb 88 11:30 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-113118-1288@Xerox>
This issue has not been distributed before. It is originally from Steele's list.
!
Issue: DISASSEMBLE-SIDE-EFFECT
References: DISASSEMBLE (p. 439), COMPILE (p. 439)
Category: CLARIFICATION
Edit history: Version 2 by Pierson 12/30/87
Version 3 by Pierson 1/21/88
Problem description:
The definition of DISASSEMBLE says that "if the relevant function is not a
compiled function, it is first compiled.". The definition of COMPILE says that
"If name is a non-nil symbol, then the compiled-function is installed as the
global function definition of the symbol...". Several implementations have
taken this to mean that if DISASSEMBLE is passed a symbol which has an
uncompiled function definition, then it has the side-effect of (COMPILE
'symbol).
Proposal (DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL):
Clarify that when DISASSEMBLE compiles a function, it will never install the
newly compiled function.
Example:
(DEFUN F (A) (1+ A))
(EQ (SYMBOL-FUNCTION 'F)
(PROGN (DISASSEMBLE 'F)
(SYMBOL-FUNCTION 'F)))
This code will return T if this proposal is adopted. Some current
implementations will return T, some will return NIL.
Rationale:
Several current implementations of DISASSEMBLE have surprising side effects,
especially for new users.
Current practice:
Allegro CL and Vax Lisp install the compiled definition. Lucid, Symbolics,
Xerox, and KCL don't install it.
Cost to Implementors:
Some implementations will have to make a simple change.
Cost to Users:
Very little. DISASSEMBLE is really part of the environment and is probably not
called by much, if any user code.
Cost of non-Adoption:
DISASSEMBLE will continue to surprise less experienced users.
Benefits:
DISASSEMBLE will become the predictable debugging function it was meant to be.
Aesthetics:
Some who worried that DISASSEMBLE was supposed to install the compiled function
may find that the language has become a little cleaner.
Discussion:
DISASSEMBLE is an environment feature; some question has been raised as to the
place and force of environment features in the standard. However, this proposal
stands if DISASSEMBLE is part of the standard language.
∂14-Feb-88 1122 X3J13-mailer Issue: DECLARE-MACROS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:22:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:21:29 PST
Date: 14 Feb 88 11:21 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DECLARE-MACROS (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Line-fold: no
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <880214-112129-1276@Xerox>
This issue was distributed in hardcopy at the November 1987 meeting.
There was some opposition at that time. This version includes a more
extensive description of possible alternative coding practices.
!
Issue: DECLARE-MACROS
References: Declaration Syntax (p154)
Category: CHANGE
Edit history: 22-Oct-87, Version 1 by Pitman
9-Nov-87, Version 2 by Masinter
5-Feb-88, Version 3 by Pitman
Problem Description:
It is permissible for a macro call to expand into a declaration and be
recognized as such. This linguistic feature provides some useful
flexibility, but has a number of disadvantages:
* Operations on the executable portion of a body of code inside a
binding form (such as inserting an additional form) is a complicated
operation. This is because one or more trial macro expansions must be
done in order to pass over any declarations or documentation string
and find the beginning of the body.
* In order to find the end of the declarations, MACROEXPAND must be
called until a non-macro form is seen or until a macro does not expand
into a macro. In some interpreters which do macro expansion on the fly,
this may cause inefficiency because macro expansion of the first form
in a body must be done twice. In implementations where this is
optimized, the implementor may resent the fact that an optimization is
needed in the first place.
* Various code analysis tools have been shown to have been significantly
slowed down by the need to expand macros in order to determine whether
a binding is SPECIAL when analyzing a variable binding form. This is
particularly serious when macro invocations are deeply nested; the
number of macro expansions can be exponential in the depth of nesting
unless a macro-expansion caching mechanism is added.
* User macros must be very careful about finding declarations in a body
of code by doing proper macro expansion. Often, however, naive users
don't realize this and so unknowingly write buggy code. This problem can
be (and is) defined away as simply a programmer error, but this is a
place where we could fairly straightforwardly redefine the language to
better accommodate what has been shown to be a common expectation of the
naive user.
Proposal (DECLARE-MACROS:FLUSH):
Under this proposal, it would not be "permissible for a macro call to
expand into a declaration and be recognized as such, provided that the
macro call appears where a declaration may legitimately appear." (CLtL
p. 154). Macros could not legitimately expand into declarations; the only
valid declarations would be a list whose CAR is the symbol DECLARE.
It would still be possible for a macro call to expand into a PROCLAIM
form, however.
Rationale:
The ability to have a macro form expand into a declaration has been shown
to be useful in some situations. More often, however, the presence of
this feature has been seen to cause problems elsewhere in the language.
Ultimately, its benefits have not outweighed its costs.
Current Practice:
Most or all implementations support the old behavior even though few
user programs probably need it.
Some user macros are careful about finding declarations in a body of code
by doing proper macro expansion, but some probably cheat and look just
for explicit uses of DECLARE. The cheat probably works most of the time.
Cost to implementors:
The nature of this change is such that implementations which did not
choose to change would simply be supporting an implementation-dependent
extension (except for some `minor' worry about destructive modification
due to macro expanding while *MACROEXPAND-HOOK* is set to something
which implemented displacing macros).
In any case, there might be several places in which the interpreter,
compiler, and system macros had knowledge about doing macro expansion
before declaration processing. The change is not trivial, but most of
its complexity is likely to be in finding the places which need change
and not in making the actual change.
Cost to users:
Most users probably do not write macros which expand into DECLARE forms
so most users are probably not affected.
Users who do exploit this feature probably know that they do. In any
case, compilers could be made to detect cases where this feature is
being exploited and warn about it.
Franz and Gold Hill are notable exceptions to the claim that users may
not want this. Both claim to make a reasonable amount of use of macros
which expand into different SPEED and SAFETY declarations, usually
dependent on a global switch.
Rewrites must be devised on a case-by-case basis. A common sort of
rewrite would take the form:
Old code: (DEFMACRO SPEEDY ()
`(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0))))
(LET (..bindings..) (SPEEDY) ..body..)
New code: (DEFMACRO SPEEDY-LET (BVL &BODY FORMS)
`(LET ,BVL
(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0)))
,@FORMS))
(SPEEDY-LET (..bindings..) ..body..)
Another tactic would be:
Old code: (EVAL-WHEN (EVAL COMPILE LOAD)
(DEFVAR *SPEEDY* NIL))
(DEFMACRO USE-STANDARD-SPEED-AND-SAFETY ()
(IF *SPEEDY*
`(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0)))
`(DECLARE (OPTIMIZE (SPEED 0) (SAFETY 3)))))
(DEFUN FOO ()
(USE-STANDARD-SPEED-AND-SAFETY)
...)
New code: (EVAL-WHEN (EVAL COMPILE LOAD)
(DEFVAR *STANDARD-SPEED-AND-SAFETY* '((SPEED 0) (SAFETY 3))))
(DEFUN FOO ()
(DECLARE (OPTIMIZE #.*STANDARD-SPEED-AND-SAFETY*))
...)
Still a third tactic would be to actually shadow DEFUN, LET, etc. with
variants that process macro expansions and then to build code in a
package that used the revised DEFUN, LET, etc. eg,
(DEFUN PARSE-BODY (BODY ENV)
(LET ((DECLS '())
(DOC '()))
(DO () ((NULL (CDR BODY)))
(LET ((EXP (MACROEXPAND (POP BODY) ENV)))
(COND ((AND (STRINGP EXP) BODY)
(UNLESS (NULL DOC)
(WARN "More than one documentation string was seen."))
(PUSH EXP DOC))
((AND (NOT (ATOM EXP)) (EQ (CAR EXP) 'DECLARE))
(PUSH EXP DECLS))
(T
(PUSH EXP BODY)
(RETURN NIL)))))
(VALUES BODY (NREVERSE DECLS) (NREVERSE DOC))))
(DEFMACRO MY:DEFUN (NAME LAMBDA-LIST &BODY DECLS-DOC-AND-FORMS
&ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
(PARSE-BODY DECLS-DOC-AND-FORMS ENV)
`(DEFUN ,NAME ,BVL ,@DECLS ,@DOC-STRINGS ,@FORMS)))
(DEFMACRO MY:LET (BINDINGS &BODY DECLS-DOC-AND-FORMS
&ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
(PARSE-BODY DECLS-DOC-AND-FORMS ENV)
`(LET ,BINDINGS ,@FORMS)))
...etc.
LAMBDA cannot be done this way, of course, since it is not a macro (or
even a special form). Support for expanding declarations in a LAMBDA
would have to be provided either by using implementation-specific support
(such as Zetalisp's ``lambda macros'') or by a workaround such as a
macro like:
(DEFMACRO LAMBDA (LAMBDA-LIST &BODY DECLS-DOC-AND-FORMS
&ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
(PARSE-BODY DECLS-DOC-AND-FORMS ENV)
`#'(LAMBDA ,BINDINGS ,@FORMS)))
Note that unlike the other examples, LAMBDA need not be (and in fact,
may not be) in the "MY" package in order for this to work since the
FUNCTION special form will generally only recognize LISP:LAMBDA.
Benefits:
The efficiency of some tools may be improved.
User macros which must do minor surgery on bodies of code will be
easier to write.
Aesthetics:
This change simplifies the semantics of the language slightly and
probably tends to better support the assumptions of naive programmers
writing macros.
In some cases involving complicated extensions to declarations, it
may be slightly harder to express such extensions in a modular way.
Experience thus far has shown such cases to be rare, however.
Discussion:
Symbolics took an in-house poll of people who take advantage of the
feature and it was generally agreed that in most cases where this
feature is used at all, that it would be just as easy to work around
using the sample rewrite techniques cited above.
Moon `credits' Pitman for (against some opposition) pushing this
`feature' down everyone's throats in the original CL design process.
Pitman admits this was an expensive mistake. Moon and Pitman support
this change as an important simplification to the language.
The cleanup committee unanimously endorsed this proposal.
In discussion at the Nov-87 X3J13 meeting, Franz and Gold Hill
mentioned that they use this feature a lot and were not entirely
happy about its going away.
∂14-Feb-88 1137 X3J13-mailer Issue: DO-SYMBOLS-DUPLICATES (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:37:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:37:58 PST
Date: 14 Feb 88 11:37 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DO-SYMBOLS-DUPLICATES (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-113758-1303@Xerox>
This issue has not been distributed to X3J13 before.
!
Issue: DO-SYMBOLS-DUPLICATES
References: DO-SYMBOLS, CLtL p.187
Category: Clarification
Edit history: Version 1 by Fahlman 17-Apr-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Nov-87
Problem Description:
CLtL specifies that DO-SYMBOLS executes the body once for each symbol accessible
in the package. It does not say whether it is permissible for the body to be
executed more than once for some accessible symbols. The term "accessible" is
defined on page 172 to include symbols inherited from other packages (not
including any symbols that may be shadowed). It is very expensive in some
implementations to eliminate duplications that occur because the same symbol is
inherited from multiple packages.
Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED
Add to the specification of DO-SYMBOLS a note that it may execute the body more
than once for some symbols.
Example:
(SETQ A (MAKE-PACKAGE 'A))
(SETQ B (MAKE-PACKAGE 'B))
(EXPORT (INTERN "ASYM" A) A)
(USE-PACKAGE A B)
(EXPORT 'B::ASYM B)
(USE-PACKAGE B A)
(DO-SYMBOLS (X B) (PRINT X))
;; this may print ASYM once or twice.
Rationale:
Most uses of DO-PACKAGE would not be harmed by the presence of duplicates. For
these applications it is unreasonable to force users to pay the high cost of
filtering out the duplications. Users who really want the duplicates to be
removed can add additional code to do this job.
Current Practice:
Many implementations have always produced duplicate values.
Cost to implementors:
None. Implemenations would still be free to eliminate the duplications, though
code will not be assuming that this has been done.
Cost to users:
Code written assuming that DO-SYMBOLS eliminates duplications will have to be
modified. (Such code was not truly portable.)
Benefits:
Clarification of a situation that is currently ambiguous.
Aesthetics:
It would be cleaner to present each symbol exactly once. This is a clear case
of choosing efficiency over elegance.
Discussion:
This issue was discussed on the Common Lisp mailing list in 1985, and the
solution proposed here seems to have been informally agreed to at the time --
there was no formal decision-making process in place then.
The need for DO-SYMBOLS to be efficient is questionable, however; for many
applications (e.g., global package manipulation), duplicate values would create
havoc.
For some implementations, the performance penalty would be well over a factor of
two.
Several proposals were considered for adding keyword arguments to DO-SYMBOLS
which might specify :ALLOW-DUPLICATES, adding keywords and eliminating
DO-EXTERNAL-SYMBOLS, etc., but no clear consensus was reached for making
additions.
This version is the closest to the status quo.
∂14-Feb-88 1155 X3J13-mailer Issue: DRIBBLE-TECHNIQUE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:55:29 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:55:39 PST
Date: 14 Feb 88 11:55 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DRIBBLE-TECHNIQUE (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-115539-1321@Xerox>
This issue has not been distributed before. (In fact, this version had not been
distributed to the cleanup committee.) There was no discussion on the issue,
however.
!
Issue: DRIBBLE-TECHNIQUE
References: DRIBBLE (p443)
Category: CLARIFICATION
Edit history: 06-Dec-87, Version 1 by Pitman
14-Feb-88, Version 2 by Masinter
Problem Description:
The intent and effect of DRIBBLE is not very clearly specified. Users have
complained that DRIBBLE behaves quite differently in different implementations.
Proposal (DRIBBLE-TECHNIQUE:MAKE-EXPLICITLY-VAGUE):
Clarify that DRIBBLE is intended primarily for interactive debugging and that
its effect cannot be relied upon from programs.
Test Case:
#1: (PROGN (DRIBBLE "temp")
(PRINT 'FOO)
(DRIBBLE))
#2: (DRIBBLE "temp")
(PROGN (PRINT 'FOO)
(DRIBBLE)
(PRINC 'BAR))
Rationale:
Users of DRIBBLE have been surprised about how differently DRIBBLE behaves in
different implementations. This makes the status quo much more explicit and will
lead to less surprise.
Current Practice:
Some implementations implement DRIBBLE as a function which simply assigns
streams such as *STANDARD-OUTPUT* to broadcast streams (or the approximate
equivalent thereof). Even within this camp, there is not widespread agreement
about which streams are affected. However, typically test case #1 will capture
the output of (PRINT 'FOO) in the file "temp" and will execute (PRINT 'BAR) but
not capture its output.
Some implementations (eg, Symbolics) push to a recursive command loop when
DRIBBLE is called with an argument, and return from that command loop when
DRIBBLE is called with no argument. In these implementations, test case #1 will
enter a recursive command loop upon the first call to DRIBBLE and will not
execute the (PRINT 'FOO) until (DRIBBLE) is done interactively. When the second
(DRIBBLE) in test case #1 is executed, DRIBBLE will complain that output is not
currently being recorded. In test case #2, the output of (PRINT 'FOO) will be
captured, but the form (PRINT 'BAR) will never be executed because (DRIBBLE)
does not return normally (it throws).
Cost to implementors:
None. This is just a clarification.
Cost to users:
Anyone who currently uses DRIBBLE in code that is believed to be portable is
kidding himself. If such code works in some implementations, it can continue to
work.
Benefits:
Users will be aware that they cannot rely on DRIBBLE in portable code.
Aesthetics:
No apparent effect.
Discussion:
DRIBBLE, like other environment features, is a standard interface to a
non-standard feature. As such, there is some question as to its place in the
ANSI standard. However, if DRIBBLE remains in the standard, its behavior is made
explicitly vague by this proposal.
∂14-Feb-88 1201 X3J13-mailer Issue: FLET-DECLARATIONS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:01:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:00:15 PST
Date: 14 Feb 88 11:59 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FLET-DECLARATIONS (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-120015-1323@Xerox>
!
Issue: FLET-DECLARATIONS
References: FLET, LABELS, MACROLET (CLtL p.113)
X3J13 document 86-003 item 113
Cleanup issue DECLARATION-SCOPE.
Cleanup issue DECLARE-MACROS.
Category: ADDITION
Edit history: Version 1, Moon, 1 Jan 1988
Version 2, Moon, 2 Feb 1988 (edits suggested by Masinter)
Problem description:
Declarations are not allowed before the body of FLET, LABELS, and MACROLET, even
though Common Lisp allows declarations in other seemingly analogous places, such
as LET.
Proposal (FLET-DECLARATIONS:ALLOW):
Change the syntax of FLET, LABELS, and MACROLET to allow declarations between
the list of local function/macro definitions and the body forms.
The scope of such declarations in FLET and LABELS includes the bodies of the
locally defined functions, when the declarations are pervasive. Non-pervasive
declarations have no effect on those bodies, except when LABELS includes the
body in the scope of a function non-pervasively declared. This paragraph
follows directly from CLtL p.155 if the locally defined function bodies are
treated like initialization forms. (This paragraph will be superseded by cleanup
issue DECLARATION-SCOPE if it passes.)
The scope of such declarations does not include the bodies of the macro expander
functions defined by MACROLET. This is consistent with the existing rule that
the bodies of those functions are in the global environment, not the local
lexical environment.
If cleanup issue DECLARE-MACROS is not passed, in MACROLET an invocation of one
of the macros locally defined by that MACROLET is permitted to expand into a
DECLARE.
Example:
(defun example (y l)
(flet ((attach (x)
(setq l (append l (list x)))))
(declare (inline attach))
(dolist (x y)
(unless (null (cdr x))
(attach x)))
l))
(example '((a apple apricot) (b banana) (c cherry) (d) (e))
'((1) (2) (3) (4 2) (5) (6 3 2)))
=> ((1) (2) (3) (4 2) (5) (6 3 2) (a apple apricot) (b banana) (c cherry))
The above function is erroneous in current Common Lisp. With this proposal, it
would have an intuitively obvious meaning.
Rationale:
This will make the syntax of FLET and LET consistent. This will make it
possible to attach declarations to function bindings; currently only variable
bindings can have attached declarations.
Current practice:
Xerox Common Lisp implements FLET-DECLARATIONS:ALLOW. Symbolics Common Lisp does
not allow declarations in this position.
Cost to Implementors:
The compilation and interpretation of three special forms will have to be
changed, however the same techniques already developed for declarations in LET
should be applicable.
Cost to Users:
No cost since this is an upward-compatible addition.
Cost of non-adoption:
Unnecessary inconsistency in the syntax of Common Lisp.
Benefits:
There is no major benefit but the language will be more consistent.
Esthetics:
Makes the language more consistent.
Discussion:
We need to resolve this for CLOS, because CLOS introduces two new special forms
similar to FLET and LABELS and we need to make their syntax consistent with FLET
and LABELS.
∂14-Feb-88 1204 X3J13-mailer Issue: FORMAT-COMMA-INTERVAL (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:03:49 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:04:24 PST
Date: 14 Feb 88 12:04 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FORMAT-COMMA-INTERVAL (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-120424-1324@Xerox>
This issue is new.
!
Issue: FORMAT-COMMA-INTERVAL
References: FORMAT integer printing (p. 388-9)
Category: ADDITION
Edit history: Version 1, Pavel, 10-Jun-87
Version 2, Masinter, 15-Jun-87
Problem description:
There are times when users would like to print out numbers with some punctuation
between groups of digits. The "commachar" argument to the ~D, ~B, ~O, ~X, and
~R FORMAT directives was introduced to fill that need. Unfortunately, the
interval at which the commachar should be printed is always every three digits.
This constraint is annoying when a different interval would be more appropriate.
Proposal (FORMAT-COMMA-INTERVAL:YES):
Add a fourth argument to the ~D, ~B, ~X, and ~O FORMAT directives, and a fifth
argument to the ~R directive, to be called the "comma-interval". This value
must be an integer and defaults to 3. When the : modifier is given to any of
these directives, the "commachar" is printed between groups of "comma-interval"
digits.
Test Cases:
Under the proposal, the following forms return the indicated values:
(format nil "~,,' ,4:B" 13) => "1101"
(format nil "~,,' ,4:B" 17) => "1 0001"
(format nil "~19,0,' ,4:B" 3333) => "0000 1101 0000 0101"
(format nil "~3,,,' ,2:R" 17) => "1 22"
(format nil "~,,'|,2:D" #xFFFF) => "6|55|35"
Rationale:
The current specification of FORMAT gives the user control over almost all of
the facets of printing integers. Only the wired-in constant for the
comma-interval remains, even though there are uses for varying that number. For
example, in many contexts, it would be convenient to be able to print out
numbers in binary with a space between each group of four bits. FORMAT does not
currently allow specification of the commachar printing interval so users
needing this functionality must write it themselves, duplicating much of the
logic in every implementation's integer printing code. Other uses, requiring
other intervals, can be imagined. For example, using a "commachar" of #\Newline
and a "comma-interval" of, say, 72, very large bignums could be printed in such
a way as to ensure line-breaks at appropriate places.
Current practice:
No released implementations currently support this feature.
Cost to implementors:
The change in the implementation of FORMAT is reasonably minor and, in most
cases, highly localized. Usually, the change is as simple as taking an extra
parameter and using it instead of a wired-in value of 3.
Cost to users:
Since the proposal involves the addition of an argument to certain directives,
the change would be entirely upward-compatible. No user code would need to be
converted.
Cost of non-adoption:
Users desiring this functionality will have to write it themselves, duplicating
much of the logic involved in printing integers at all.
Benefits:
One of the few remaining inflexibilities in integer printing is eliminated with
a net increase in user-visible functionality.
Esthetics:
By parameterizing one of the final pieces of wired-in behavior from integer
printing, this small part of the workings of FORMAT would be perceived as having
been cleaned up.
Discussion:
Several members of the cleanup committee endorsed this proposal. No objections
were raised.
∂14-Feb-88 1214 X3J13-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:14:19 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:14:54 PST
Date: 14 Feb 88 12:14 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-121454-1351@Xerox>
This issue is new.
!
Issue: FORMAT-COLON-UPARROW-SCOPE
References: CLtL p. 406 and also p. 403
Category: CLARIFICATION
Edit history: version 1: Guy Steele, 30 November 1987
version 2: Guy Steele, 18 January 1988
version 3: Masinter, 5 February 1988
Problem description:
Implementations currently differ on the question of what is tested by the FORMAT
command "~:↑". Some implementations test to see whether any arguments remain in
the sublist for the current iteration step; others test to see whether any
sublists remain. The text on page 406 is not clear on this point.
Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS):
~:↑ may be used only if the command it would terminate is ~:{ or ~:@{. The
entire iteration process is terminated if and only if the sublist that is
supplying the arguments for the current iteration step is the last sublist (in
the case of ~:{) or the last FORMAT argument (~:@{). Note that ~:↑ is *not*
equivalent to ~:#↑; the latter terminates the entire iteration if and only if no
arguments remain for the current iteration step.
Example:
(format nil "~:{~@?~:↑...~}" '(("a") ("b")))
Under this proposal, this yields "a...b", rather than "a".
Rationale:
This proposal is desirable because otherwise there is no way to test whether any
sublists remain. The text on page 406 may be construed to hint at this proposal
indirectly. To quote Nick Gall:
"If one thinks about the intent of the parenthetical `(because in the standard
case it tests for remaining arguments of the current step only)', one should
agree that "a...b" will be returned. In referring to ~↑ as the `standard case',
which tests the arguments remaining in the current argument sublist, this
parenthetical implies that there is an `other case', which tests `something
else.' The only `other case' discussed is ~:↑, which therefore must test
`something else.' I claim that the parentheical makes no sense if we interpret
~:↑ as testing the same condition as ~↑. If they both test the same condition,
why have the parenthetical explanation?
"If ~:↑ doesn't test the same condition as ~↑, then what does it test? I claim
that the only test that makes sense is for ~:↑ to test the only thing that
affects the `entire iteration process:' the number of sublists. When there are
no more sublists, `the entire iteration process' is terminated."
Current practice:
Some implementations already have the proposed behavior, including Symbolics
Common Lisp and TI Lisp.
Many other implementations currently have a different interpretation: the test
case returns "a", since ~:↑ in those implementations test for the remaining
arguments rather than remaining sublists. These currently include Kyoto Common
Lisp, Allegro Common Lisp, GCLISP, Xerox Common Lisp, Spice Lisp, and VAXLISP.
Cost to Implementors:
Many implementations will have to make a small change, probably a one-liner.
Cost to Users:
It is unlikely that much user code depends on the behavior of testing for
remaining arguments, but it is possible. The author of this writeup (Steele)
judges it somewhat more likely that user code might depend on the behavior of
testing for remaining sublists.
Cost of non-adoption:
Users would have to be warned not to use ~:↑ in code that is meant to be
portable.
Benefits:
Elimination of yet one more ambiguity. The proposed semantics allows greater
semantic power (there are more things one can test).
Esthetics:
``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele Jr.
Discussion:
Guy Steele very strongly prefers the interpretation
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
David Moon, Kent Pitman, Pavel Curtis, Dan Pierson, Rob Poor, Scott Fahlman and
Nick Gall favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
Kevin Layer and Rich Robbins have spoken in favor of an alternative proposal, to
test for the remaining arguments.
Historical note: Steele first implemented this "feature", in Zetalisp, and so
the code in Symbolics Common Lisp is likely a direct descendant of the original
code. This might cause some to give weight to Steele's opinion. There are two
arguments against such credence. First, there is no reason why the original
code should be regarded as part of the specification of Common Lisp any more
than any other implementation; plainly, Steele botched the specification when he
wrote the book. Second, a professor of literature (I believe) once told Isaac
Asimov concerning a short story of his (I quote from memory): "Tell me, Dr.
Asimov, just because you wrote the story, what makes you think you know what it
means?"
∂14-Feb-88 1223 X3J13-mailer Issue FUNCTION-TYPE-KEY-NAME, Version 3
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:23:25 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:23:55 PST
Date: 14 Feb 88 12:23 PST
From: Masinter.pa@Xerox.COM
Subject: Issue FUNCTION-TYPE-KEY-NAME, Version 3
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-122355-1354@Xerox>
This issue is new.
!
Issue: FUNCTION-TYPE-KEY-NAME
References: CLtL p.47-48, 61
Category: CLARIFICATION, CHANGE
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(from comments by Kent Pitman)
Version 3, 13-Feb-88 Masinter
Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT,
KEYWORD-ARGUMENT-NAME-PACKAGE
FUNCTION-ARGUMENT-TYPE-SEMANTICS
Problem description:
The FUNCTION type specifier list is provided to allow declaration of function
argument types and return value types. This type specifier uses a syntax
similar to the usual lambda list syntax to specify which types go with which
lambda list variables. However, there is a problem with &KEY lambda variables
because CLtL does not specify how the types specified in the FUNCTION
declaration are matched up to either the actual arguments passed to the
function, or the lambda variables in the function definition (since the ordering
of keyword arguments is arbitrary).
Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD):
(1) Specify that the &KEY parameters in a FUNCTION type specifier lambda list
should be supplied as lists of the form (<keyword> <type>). The <keyword> must
be a valid keyword-name symbol as must be supplied in the actual arguments of a
call. (This is usually a symbol in the keyword package, but, as per
KEYWORD-ARGUMENT-NAME-PACKAGE, not necessarily so.)
(2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda list.
The interpretation of such declarations is that, when &KEY is given in a
FUNCTION type specifier lambda list, it is safe to assume that the &KEYs given
are exhaustive unless &ALLOW-OTHER-KEYS is present.
&ALLOW-OTHER-KEYS is an indication that other keyword arguments may actually be
supplied and, if supplied, may be used.
Example:
The type of the function MAKE-LIST could be declared as:
(FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST)
Rationale:
(1) This specifies a direct correspondence between the argument type and its
matching keyword. All of the information is in one place, and the user does not
have to remember (or even know) the order in which &KEY arguments appear in the
actual function definition.
(2) This is probably an oversight in the original specification.
Current practice:
Many Common Lisp implementations currently ignore FUNCTION type declarations.
The situation regarding type specifications for keyword arguments is so
ambiguous that few users attempt to use them.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier or keyword arguments in
a FUNCTION type specifier may continue to do so. This proposal should not
involve massive amounts of code to be rewritten.
Cost to users:
Because the current situation is so ambiguous, FUNCTION type specifiers and
particularly the specification of keyword argument types are not widely used.
However, since this is an incompatible change, it would be nice if
implementations check for, and warn about, old-style usage.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of limited
use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language design.
Esthetics:
The syntax is fairly obvious and is analogous to the (<keyword> <variable>)
lambda list syntax.
Discussion:
The exact semantics of function declarations and the types of arguments is
still under discussion, as are several other issues dealing with declarations.
However, this issue seemed separable.
∂14-Feb-88 1231 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:31:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:29:51 PST
Date: 14 Feb 88 12:29 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-122951-1359@Xerox>
This issue is new.
!
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p. 27, 47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(incorporate comments from Scott Fahlman & others)
Version 3, 13-Feb-88 Masinter
Related issues: FUNCTION-TYPE-KEY-NAME,
FUNCTION-ARGUMENT-TYPE-SEMANTICS
Problem description:
The FUNCTION type specifier list is provided to allow declaration of function
argument types and return value types. This type specifier uses a syntax
similar to the usual lambda list syntax to specify which types go with which
lambda list variables. However, this is actually of limited usefulness in the
context of a declaration, where one normally wants type information about the
actual arguments which can be passed to the function rather than the lambda
variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST. For the sake of consistency, it would seem that
the corresponding type given in the FUNCTION declaration must also be LIST, but
since this provides no information about the actual arguments, some
users/implementors have instead adopted the convention of supplying the type of
the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the type
specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided with
&REST is the type of each actual argument, not the type of the corresponding
lambda variable.
Example:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must be
LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Most Common Lisp
implementations currently ignore FUNCTION type declarations. The only examples
found so far are in a text book on Common Lisp, which follows the proposed
syntax.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do so.
Probably only a small amount of code would have to be written/changed in
implementations that currently think that the &REST argument should be LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must be
LIST will have to change their code. However, because this issue is so unclear,
the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of limited
use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language design.
Esthetics:
Debatable. One the one hand, since the argument type syntax used by the
FUNCTION type specifier mirrors
normal lambda-list syntax, it would be cleaner and less confusing to provide the
type of the lambda variable rather than the type of the actual arguments.
However, considering the types specified in the FUNCTION specifier to be the
types of the actual arguments rather than the types of the parameters as seen on
the receiving end makes the proposed semantics more palatable.
Discussion:
This issue provoked considerable debate in the cleanup committee. There was some
support for an alternative proposal to require that the &REST argument
declaration, if any, always be LIST or a subtype of LIST, and to extend the LIST
type to allow declarations of the form, e.g., (LIST NUMBER).
Those who favor USE-ACTUAL-ARGUMENT-TYPE (including David Moon and Larry
Masinter) argue that the simplicity of the declarations and the ugliness of the
alternative, as well as the weight of current practice, argue for it.
Kent Pitman has argued against this proposal on the following grounds:
``* It is bothersome that the same argument declarations which are used
internally in the function would not be be usable externally.
``* It is unfair to provide only this special-purpose way of declaring a
sequence type when in fact there are numerous other places in the language where
it might be useful to declare a sequence type.
``If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated explicitly (if
it is not already in CLtL somewhere) that the following is illegal:
(DEFUN FOO (&REST X) X)
(APPLY #'FOO T)
since there will be no way to type-declare this. Even though this is an obscure
case (that doesn't even work in some implementations), it's the sort of thing
that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE.''
∂14-Feb-88 1301 X3J13-mailer Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:00:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:58:56 PST
Date: 14 Feb 88 12:58 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-125856-1384@Xerox>
This issue passed conditionally at the June 1987 meeting; this revision was
distributed at the November 1987 meeting.
!
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter
(no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
Version 2 29-May-87, extracted again
Version 3 5-Jun-87, by Masinter
Version 4 11-Jun-87, for release
Version 5 13-Jul-87, by Masinter
Problem Description:
If a macro that performs similar processing to SETF uses GET-SETF-METHOD, and
that macro occurs within a MACROLET, the expansion will not see the MACROLET
definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it defaults to
the null lexical environment. NIL can also be passed explicitly to denote the
null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the environment
to GET-SETF-METHOD.
Clarify that, within the scope of a MACROLET, FLET and LABELS, global SETF
definitions of the name defined by the MACROLET, FLET or LABELS do not apply. A
SETF method applies only when the global function binding of the name is
lexically visible. All of the built in macros of Common Lisp (SETF, INCF, DECF,
POP, ROTATEF, etc.) which modify location specifications obey this convention.
Test Case:
;;; This macro is like POP
(defmacro xpop (place &environment env)
(multiple-value-bind (dummies vals new setter getter)
(get-setf-method place env)
`(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
(prog1 (car ,(car new))
(setq ,(car new) (cdr ,(car new)))
,setter)))))
(defsetf frob (x) (value)
`(setf (car ,x) ,value))
;;; The following will modify (cdr z) and not (car z)
(macrolet ((frob (x) `(cdr ,x)))
(xpop (frob z)))
;;; The following is an error; an error may be signaled at macro expansion time
(flet ((frob (x) (cdr x))
(xpop (frob z)))
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although some do
not. One implementation has extended GET-SETF-METHOD to take an optional
argument which is incompatible with this use.
Cost to implementors:
Some implementations will have to add this feature, although it is not a major
change.
Cost to users:
This is generally an upward compatible change. In implementations which did not
already take into account the lexical environment for SETF'd forms might start
working differently if the internal implementation of SETF is changed. The
likelihood of this affecting a user's program is very small.
Benefits:
This change improves portability and the ability to use MACROLET, FLET and
LABELS in portable code which might also have SETF forms.
Aesthetics:
SETF methods cannot work correctly within lexically defined function symbols
without this change. This change makes the language more consistent and correct.
Discussion:
The cleanup committee generally supports this change.
A number of additional changes for rationally dealing with lexical environments
as first class objects, including a more general set of accessors and
constructors for lexical environments is required for many language extensions
(e.g., a portable version of the proposed Common Lisp Object System) and should
be addressed by a future proposal. For a while, the cleanup committee attempted
to deal with these issues together, but decided to separate them out into their
component parts. This issue is the simplest.
∂14-Feb-88 1310 X3J13-mailer Issue: PATHNAME-STREAM (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:10:14 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:10:49 PST
Date: 14 Feb 88 13:10 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 6)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-131049-1395@Xerox>
Version 2 conditionally passed X3J13/Jun87. Version 6 was distributed in
hardcopy form X3J13/Nov87.
!
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: TRUENAME (p.413), PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Version 3 by Masinter 11-Jun-87 (minor editing)
Version 4 by Masinter 8-Oct-87 (rewording)
Version 5 by Masinter 8-Oct-87 (explicitly only open)
Version 6 by Masinter 14-Nov-87
Category: CHANGE/CLARIFICATION
Problem Description:
CLtL says that a stream can be used as an argument and converted to a pathname,
but many sources or sinks of data that streams might be connected to have no
pathnames associated with them; for example, streams created with
MAKE-TWO-WAY-STREAM or OPEN-STRING-STREAM. For many such streams, there is no
simple way to coerce such a stream to a pathname.
Proposal PATHNAME-STREAM:FILES-OR-SYNONYM:
Clarify that the use of a stream as an argument that expects a pathname (as
described on p413 of CLtL) only applies to streams that are originally opened by
use of the OPEN or WITH-OPEN-FILE, or to synonym streams whose symbol is bound
to such a stream. It is an error to attempt to obtain a pathname from a stream
created with MAKE-TWO-WAY-STREAM, OPEN-STRING-STREAM, MAKE-ECHO-STREAM,
MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-STRING-INPUT-STREAM,
MAKE-STRING-OUTPUT-STREAM.
The pathname used represents the name used to open the file. This may be, but is
not required to be, the actual name of the file. The pathname used is the same
as would be returned by the PATHNAME function.
Rationale:
This is probably what the designers of Common Lisp intended. This is the only
thing that can be implemented without large changes to the language such as
extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname. Others
return an empty pathname.
Some implementations do not return a meaningful value for PATHNAME of a synonym
stream.
Adoption Cost:
Implementations that do not currently handle PATHNAME of a synonym stream will
have to change to allow it. Otherwise, since the proposal says only "is an
error" rather than "signals an error", no implementations other changes are
necessary.
Benefits:
The description of pathname functions will make more sense.
Conversion Cost:
Small: Users with code which accesses pathname components of streams in
implementations which allow it might need to change their programs to make them
portable.
Aesthetics:
Makes language a little cleaner.
Discussion:
The only point of disagreement on this proposal has been on the issue of whether
PATHNAME applies to synonym streams and returns the pathname of the stream
designated.
This version of the proposal says yes, because CLtL p 329 says about synonym
streams that "Any operations on the new stream ..." and does not say anything
about exceptions; earlier on the page the phrase "synonym streams that pass all
operations on" is used. This seems fairly unambiguous, although the word
"operations" is not defined. There was a similar controversy about what CLOSE of
a synonym stream means.
Note that there is currently no way portable to determine whether a stream has a
pathname available.
The entire PATHNAME section needs work to clarify the intent and enable portable
code. This is just a minor issue among the major ones.
∂14-Feb-88 1306 X3J13-mailer Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:06:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:07:20 PST
Date: 14 Feb 88 13:06 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-130720-1391@Xerox>
Version 6 conditionally passed X3J13/Jun87. Version 8 distributed in hardcopy
form X3J13/Nov87.
!
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
5-Jun-87, Version 5 by Masinter
11-Jun-87, Version 6 by Masinter
23-Oct-87, Version 7 by Masinter
8-Nov-87, Version 8 by Moon
Problem Description:
CLtL says that only keyword symbols can be used as keyword-names in
&key parameter specifiers (page 60, "each -keyword- must be a
keyword symbol, such as :start.")
As Common Lisp is currently defined, if someone wants to define a
function that accepts keyword (rather than positional) arguments whose
keyword-names are symbols in packages other than the KEYWORD package,
they cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of the keyword-names of keyword
parameters; allow any symbol. That is:
If, following an &KEY, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword symbol with the same print name as the variable is created and
is used as the keyword-name when matching arguments to parameter
specifiers. A keyword-name that is not a keyword symbol can be
specified with the ((-keyword- -var-) ...) syntax of parameter
specifier. The -keyword- can be any symbol, not just a keyword.
A future specification of Common Lisp could be written with revised
terminology that did not use the term "keyword" to refer to three
different things: symbols in the KEYWORD package, symbols beginning
with & that have special meaning in lambda-lists, and keyword-names
used to match function arguments to keyword parameter specifiers.
However, this proposal does not propose to change any terminology.
Test case:
(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
keyword-names to be symbols, and disallowing numbers, but does not
speak to the issue of whether or not those symbols should be further
restricted to be in the KEYWORD package.
The desire for keyword parameters whose keyword-names are not in the
KEYWORD package arises when the set of keyword-names accepted by a
function is the union of the sets of keyword-names accepted by several
other functions, rather than being enumerated in a single place. In
this case, it becomes desirable to use packages to prevent accidental
name clashes among keyword-names of different functions.
One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS). It will have generic functions that accept arguments and pass
them on to one or more applicable methods, with each method defining its
own set of keyword-names that it is interested in. If this proposal is
not adopted, either the keyword-names will be required to be keywords,
which will require the methods to have non-modular knowledge of each
other in order to avoid name clashes, or the methods will have to be
defined with an ad hoc mechanism that duplicates the essential
functionality of &key but removes the restriction.
A second example of a Common Lisp application that requires this
capability is private communication channels between functions. Suppose
a public routine MAKE-FOO needs to accept arbitrary arguments from the
caller and passes those arguments along to an internal routine with
additional arguments of its own, and suppose that keyword parameters
are used to receive these arguments.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST NAME-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T NAME-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override some argument in NAME-VALUE-PAIRS, since the only way
that could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT
NIL), or if the user was programming explicitly in the FOOLAND package,
either of which is an implicit admission of willingness to violate
FOOLAND's modularity.
Documentation Impact:
Some careful rewording of the existing language in CLtL is necessary in
the standard to avoid confusion between "keyword", indicating a symbol
in the KEYWORD package, and "keyword name", indicating a syntactic part
of a keyword parameter specifier. It is likely that this is best served
by changing those instances of "keyword" to "named argument" when the
specification is discussing the indicator which introduces an actual
parameter in a call to a function defined with &KEY.
The wording which refers to named arguments as being introduced by
keyword symbols would change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each named argument name must be a symbol.
The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.
Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as the names for named
arguments, and that all functions built into the Common Lisp language
follow that convention.
Examples would be useful. On p.64 the following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)
Cost to implementors:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Cost to users:
None--no existing programs will stop working.
Benefits:
This will help with the object-oriented programming standard, among
other things.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is more
aesthetic or less aesthetic than the freedom, but in either case the
aesthetic effect is slight.
In any case, users who do not want to use the extended functionality can
generally avoid it.
Discussion:
The cleanup committee generally supports this extension.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but may be mistaken.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
The cleanup committee considered, but did not adopt, a proposal to
exclude NIL as a legal indicator. It might catch some errors, but is
otherwise an odd restriction.
∂14-Feb-88 1300 X3J13-mailer Issue: FUNCTION-TYPE (version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:00:37 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:55:41 PST
Date: 14 Feb 88 12:55 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 9)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
LINE-FOLD: NO
Message-ID: <880214-125541-1381@Xerox>
This is a difficult issue. The issue was discussed both at the June and November 1987 meetings. There seem to be strong opinions along several different dimensions.
This version of the issue writeup contains two different proposals.
!
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
There are two proposals for dealing with this issue.
!
Proposal FUNCTION-TYPE:CONSERVATIVE
1. Introduce a new type PROCEDURE that can be used both for declaration
and discrimination.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and PROCEDURE
are pairwise disjoint. In particular, a list may not be used
to implement any PROCEDURE subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of PROCEDURE.
Implementations are free to define other subtypes of PROCEDURE.
1c. Introduce a new function, PROCEDUREP, such that
(PROCEDUREP x) == (TYPEP x 'PROCEDURE).
2. Define that a ``function'' may be a procedure, a list whose car is
the symbol LAMBDA, or any symbol (whether fbound or not).
2a. Clarify that the FUNCTION type behaves as if it had been
defined by:
(DEFUN LAMBDA-P (X) (AND (NOT (ATOM X)) (EQ (CAR X) 'LAMBDA)))
(DEFTYPE FUNCTION ()
`(OR SYMBOL (SATISFIES LAMBDA-P) PROCEDURE))
2b. Clarify that (FUNCTIONP x) == (TYPEP x 'FUNCTION).
This change is compatible.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Clarify that FUNCALL and APPLY continue to accept functions
as arguments. However, some implementations may produce better
code for expressions such as (FUNCALL (THE PROCEDURE ...) ...)
or (APPLY (THE PROCEDURE ...) ...).
3. Clarify that the result of a FUNCTION special form must be a procedure.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE PROCEDURE (FUNCTION name)). As such, the potential
optimizations mentioned in 2e are also possible for
(FUNCALL (FUNCTION ...) ...) and (APPLY (FUNCTION ...) ...).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that it is permissible for FBOUNDP to return true for a macro
or special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound,
(PROCEDUREP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).
5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error,
but they are also permitted to define useful (non-portable)
interpretations.
5d. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
Implementations are permitted, but not required, to store
information about a global macro-function or special form
in the function cell. This definition of SYMBOL-FUNCTION
is intended to leave enough freedom for such implementations
to conveniently implement FUNCTION, SPECIAL-FORM-P, and
MACRO-FUNCTION using SYMBOL-FUNCTION as the underlying
subprimitive.
6. COERCE is extended to allow objects to be coerced to type procedure.
6a. (COERCE symbol 'PROCEDURE) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
6b. (COERCE lambda-expression 'PROCEDURE) is equivalent to
(EVAL `(FUNCTION ,lambda-expression)).
7. Clarify *MACROEXPAND-HOOK* is permitted to contain any kind of function.
The function is coerced to a procedure before being called as the
expansion interface hook by MACROEXPAND-1.
!
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
STRICT-REDEFINITION is similar to CONSERVATIVE, except that it redefines
the type FUNCTION instead of adding a new type PROCEDURE, and it restricts
coercion by functions that take functions as arguments. The numbering of
CONSERVATIVE is preserved for comparison.
1. Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint. In particular, a list may not be used
to implement any PROCEDURE subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
2. Define that a ``function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.
2a. This type no longer includes objects of type SYMBOL or lists
with CAR = LAMBDA.
2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible
change.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Change FUNCALL and APPLY such that they accept only a function
as the functional argument. This restriction is inherited by
all functions in Common Lispthat take a functional argument.
It is no longer legal to pass a symbol or lambda expression as
the functional argument to any of these functions; to do so
"is an error".
3. Clarify that the result of a FUNCTION special form must be a function.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that it is permissible for FBOUNDP to return true for a macro
or special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound,
(FUNCTIONP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).
5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error.
5d. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
6. COERCE is extended to allow objects to be coerced to type procedure.
6a. (COERCE symbol 'FUNCTION) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
6b. (COERCE lambda-expression 'FUNCTION) is equivalent to
(EVAL `(FUNCTION ,lambda-expression)).
7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the
expansion interface hook by MACROEXPAND-1.
!
Rationale:
Since the two proposals are similar, they are discussed together. Where
motiviation and justification differ, the proposals are referred to by
name (STRICT-REDEFINITION, CONSERVATIVE.)
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
CONSERVATIVE manages a compatible definition with most existing uses of
the term ``function'' while providing a graceful upgrade path to the term
``procedure'' for use in situations that call for a higher degree of clarity.
STRICT-REDEFINITION avoids introducing a new term at the cost of
incompatible change.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is the same as (FUNCTIONP x).
In some implementations, (TYPEP x 'FUNCTION) is the same as what
CONSERVATIVE calls (TYPEP x 'PROCEDURE).
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations are likely to have exactly the
semantics described in either. CONSERVATIVE is more compatible with
current practice than STRICT-REDEFINITION, however.
Cost to Implementors:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations. While STRICT-REDEFINITION makes it an error to pass
non-function arguments to APPLY, FUNCALL etc, there is no requirement
to check for that error.
Compiled functions are true functions in almost all current
implementations, but in many implementations, interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, this representation would have to be different
(implemented either as structures or to some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).
Cost to Users:
The conversion cost associated with CONSERVATIVE is very low because the
model of FUNCTIONP which it takes is largely consistent with existing
practice.
The new features introduced by CONSERVATIVE, particularly the PROCEDURE
data type, can be converted to fairly lazily.
The conversion cost for the STRICT-REDEFINITION proposal is higher. The
changes to FUNCTIONP and the FUNCTION type declaration is relatively easy
to deal with. However, the strict redefinition of FUNCALL, APPLY and
functional arguments will require the addition of an explicit coercion
would have to be added whenever a symbol or lambda expression is used as
a functional argument. Many such cases can be identified at compile time,
but not all.
Some implementations might provide tools to assist in detecting implicit
coercion of symbols to functions. For example, an implementation might add
run-time test in which the implementation still does the coercion but that
issues a warning message whenever the coercion is actually needed.
Alternatively, a "smart" code-walker or editor macro might find all of the
calls to FUNCALL, APPLY, and the 61 Common Lisp functions that take :TEST
or :KEY arguments and, if the argument is not already an explicitly quoted
FUNCTION form, wrap a COERCE around the body.
For either proposal:
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell might have to change. Such code was
already not portable, however, since some implementations signal an error
when this is done.
Benefits:
For CONSERVATIVE:
The term ``function'' would be given a useful meaning that was relatively
compatible with existing usage.
A new term ``procedure'' would be available for descriptional clarity.
The new PROCEDURE datatype would be useful for type discrimination in CLOS.
For STRICT-REDEFINITION:
The term ``function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.
STRICT-REDEFINITION provides useful constraints which will be of aid
to systems doing automatic program analysis for the purpose of
``selective linking.'' Such tools may in turn make it possible to
reduce the total size of a delivered application program because
only those Common Lisp functions that are actually called need to be
included.
For either proposal:
The type hierarchy would be simplified.
Either proposal brings Common Lisp into closer alignment with Scheme and
the work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with this proposal.
Aesthetics:
Both proposals improve the aesthetics of the language.
Discussion:
These proposals have been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Many different alternatives have been discussed both in the cleanup committee
and X3J13. These two proposals are the distillation of the alternatives.
The CONSERVATIVE proposal offers the advantage of backward compatibility,
and considerably more flexibility in the language.
The STRICT-REDEFINITION proposal offers the advantage of a slightly cleaner
resulting language.
Some concerns were raised about STRICT-REDEFINITION in a previous discussion
about "late binding" of function definitions. Neither proposal disallows
late binding of symbols to functions. For example, in the call
(MAPCAR #'FROB my-list)
the effect of the FUNCTION special form (as generated by the #' read macro)
is to obtain the function definition of FROB at the time the #'FROB is
evaluated. Neither proposal changes this.
Currently, it is allowed to write
(MAPCAR 'FROB my-list)
while this form would no longer be allowed under the STRICT-REDEFINITION
clause. Currently, neither CLtL nor the CONSERVATIVE proposal addresses
the question of the time at which FROB's function definition is obtained;
if, during the processing of my-list, FROB is redefined, it is not clear
whether the processing of subsequent elements would be changed.
∂14-Feb-88 1328 X3J13-mailer Issue: PATHNAME-SYMBOL (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:28:34 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:26:37 PST
Date: 14 Feb 88 13:26 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-SYMBOL (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-132637-1426@Xerox>
My notes are unclear. This issue may have been distributed before.
!
Issue: PATHNAME-SYMBOL
References: PATHNAME (p.413),
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
NAMESTRING etc. (p.417), LOAD (p. 426), REQUIRE
Cleanup issue PATHNAME-STREAM
Common LispCraft, Wilensky 1986, p 51
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Oct-87
Version 4 by Masinter 23-Nov-87
Version 5 by Masinter 5-Feb-88, fix minor typo
Category: CHANGE
Problem Description:
Some Common Lisp functions are specified to accept a symbol where a pathname is
expected. Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE, and RENAME-FILE) are
not specified to accept a symbol.
Proposal PATHNAME-SYMBOL:NO
Never allow symbols where pathnames are expected. More specifically, PATHNAME,
TRUENAME, PARSE-NAMESTRING, MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE,
PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING,
FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING,
REQUIRE are changed by this proposal to not allow symbols for their pathname
argument.
Reiterate that OPEN, WITH-OPEN-FILE, LOAD, COMPILE-FILE, RENAME-FILE,
DELETE-FILE, FILE-WRITE-DATE, FILE-AUTHOR do not allow symbols for their file or
filename argument, and that DIRECTORY does not allow a symbol for its pathname
argument. This is implied by the respective descriptions of those functions in
CLtL, but not explicitly stated.
Rationale:
Allowing symbols for pathnames was based on an obsolete practice in MacLisp
(which did not have strings) and causes much error-prone behavior.
Current Practice:
Varies. Some implementations allow symbols here, some don't. Symbolics doesn't
allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES, and allowing them
there is probably a bug in the implementation.
Cost to implementors:
It's easy to change implementations to stop accepting symbols. Since this
appears to be an "is an error" rather than "signals an error" situation, no
implementation change is actually necessary.
Cost to users:
Some users might be using symbols as pathnames, in implementations where that
works, and they would have to switch to using strings. For example, some users
are used to typing interactively (LOAD 'FOO) to mean (LOAD "FOO"). This is not
explicitly allowed in CLtL, so such behavior has not been portable. However,
such use is probably widespread among users of implementations that allow it
(e.g., Common LISPCraft gives this form in an example.)
Benefits:
Pathname functions will be more consistent. In implementations that check the
type of this argument, program error checking will be improved. In dealing with
case-sensitive file systems, users won't do (load 'foo) and wonder why file
"FOO" (rather than "foo") is not found.
One example of the type of bug caused by this occurs when NIL is erroneously
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find a table
entry that was expected to exist and returned -false-. In systems that accept
symbols as pathnames, this causes a reference to a file named "NIL" on some
perhaps unexpected directory.
Aesthetics:
Improved by the change.
Discussion:
Some users have reported that they thought MERGE-PATHNAMES was in error because
it accepted symbols.
We believe that this feature was accidentally introduced as a historical
artifact and that it has limited utility. It is likely that the feature of
accepting a symbol was copied by Common Lisp from Zetalisp, which in turn copied
it from Maclisp. The reason Maclisp allowed a symbol here was that it did not
have strings at all. While the feature was removed from Zetalisp before Common
Lisp was defined due to the poor state of Zetalisp documentation at the time the
change was overlooked by the designers of Common Lisp.
If a symbol can be coerced into a string, and a string can be coerced into a
pathname, why can't a symbol be coerced into a pathname? An explicit decision
was made early in the design of CL not to make all coercions transitive. For
example, symbols coerce to strings (for string functions), and strings are
sequences (and so can be mixed with other sequence types), but symbols are not
sequences.
There is some sentiment for extending COERCE to allow explicit coersion of
STRINGs to PATHNAMEs, as a separate cleanup item.
A careful reading of CLtL indicates that it is possible for an implementation to
allow a symbol to be a STREAM (there is no requirement that STREAM and SYMBOL be
disjoint.) While there is some sentiment for making this requirement in a
separate cleanup issue, it would otherwise prevent both symbol->pathname and
stream->pathname to have consistent meaning.
∂14-Feb-88 1338 X3J13-mailer Issue: PUSH-EVALUATION-ORDER (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:38:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:37:53 PST
Date: 14 Feb 88 13:37 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PUSH-EVALUATION-ORDER (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-133753-1430@Xerox>
I believe this issue was not distributed before.
!
Issue: PUSH-EVALUATION-ORDER
References: CLtL p. 99 (generalized variables)
p. 270 (PUSH)
All macros that manipulate generalized variables
(SETF, PSETF, GETF, REMF, INCF, DECF, PUSH, PUSHNEW,
POP, CHECK-TYPE, ASSERT, CTYPECASE, CCASE, SHIFTF,
ROTATEF, and all macros defined by DEFINE-MODIFY-MACRO).
Issue SETF-FUNCTION-VS-MACRO.
Category: CLARIFICATION
Edit History: Version 1, 15-Oct-87, Jeff Peck
Version 2, 23-Oct-87, Larry Masinter
Version 3, 8-Nov-87, David Moon
Version 4, 14-Nov-87, Larry Masinter
Version 5, 25-Nov-87, Larry Masinter
Problem Description:
In the form (PUSH (ref1) (CAR (ref2))) It is unclear whether (ref1) should be
evaluated before (ref2).
CLtL, page 99, in a discussion of generalized variable macros, states:
"Macros that manipulate generalized variables must guarantee the `obvious'
semantics: subforms of generalized-variable references are evaluated ... in
exactly the same order as they appear in the *source* program. The expansion of
these macros must consist of code that follows these rules or has the same
effect as such code. This is accomplished by introducing temporary variables
bound to the subforms of the reference."
This paragraph and a discussion of SETF on the previous pages may also be
interpreted as requiring that *all* subforms of such macro calls should be
evaluated once, in source order, left to right.
However, CLtL, page 270 states:
"The effect of (PUSH Item Place) is roughly equivalent to
(SETF Place (CONS Item Place))
except that the latter would evaluate any subforms of Place twice while PUSH
takes care to evaluate them only once."
Place and Item appear in different order in the PUSH form and the indicated
equivalent SETF form. Should the PUSH form have primacy over the obvious SETF
form with respect to the left-to-right evaluation?
Are all subforms in a macro call guaranteed to be evaluated in order, or only
those subforms representing generalized variable references?
The same question arises for other forms which manipulate generalized variables,
e.g., PUSHNEW, INCF, DECF, and those defined with DEFINE-MODIFY-MACRO.
Proposal: PUSH-EVALUATION-ORDER:ITEM-FIRST
This proposal is hard to state, although the intent is fairly clear: evalution
proceeds from left to right whenever possible. The left-to-right rule does not
remove the obligation on writers of macros and define-setf-method to ensure
left-to-right order, however.
In this proposal, a form is something whose syntactic use is such that it will
be evaluated. A "subform" means a form that is nested inside another form -- not
any object nested inside a form regardless of syntactic context.
(1) The evaluation ordering of subforms within a generalized variable reference
is determined by the order specified by the second value returned by
GET-SETF-METHOD. For all predefined generalized variable references (GETF, LDB),
this order of evaluation is exactly left-to-right. When a generalized variable
reference is derived from a macro expansion, this rule is applied *after* the
macro is expanded to find the appropriate generalized variable reference.
This is intended to make it clear that if the user writes a DEFMACRO or
DEFINE-SETF-METHOD that doesn't preserve order, the the order specified in the
user's code holds; e.g., given
(DEFMACRO WRONG-ORDER (X Y) `(GETF ,Y ,X))
that (PUSH <value> (WRONG-ORDER <place1> <place2>)).
will evaluate <place2> first and then <place1> because that is the order they
are evaluated in the macro expansion.
(2) For the macros that manipulate generalized variables (PUSH, PUSHNEW, GETF,
REMF, INCF, DECF, SHIFTF, ROTATEF, PSETF, SETF, POP, and those defined with
DEFINE-MODIFY-MACRO) the subforms of the macro call are evaluated exactly once
in left to right order, with the subforms of the generalized variable references
evaluted in the order specified in (1).
PUSH, PUSHNEW, GETF, REMF, INCF, DECF, SHIFTF, ROTATEF, PSETF, POP evaluate all
subforms before modifying any of the generalized variable locations. SETF (in
the case when the SETF macro has more than two arguments) performs its operation
on each pair in sequence, i.e., in (SETF <place1> <value1> <place2> <value2>
...), the subforms of <place1> and <value1> are evaluated, the location
specified by <place1> is modified to contain the value returned by <value1>, and
then the rest of the SETF form is processed in a like manner.
(3) For the macros CHECK-TYPE, CTYPECASE, and CCASE, subforms of the generalized
variable reference are evaluted once as in (1), but may be evaluted again if the
type check files in the case of CHECK-TYPE or none of the cases hold in
CTYPECASE and CCASE.
(4) For the macro ASSERT, the order of evaluation of the generalized variable
references is not specified.
(Rules 2, 3 and 4 cover all macros defined in Common Lisp that manupulate
generalized variable references.)
Examples:
(LET ((REF2 (LIST '())))
(PUSH (PROGN (PRINC "1") 'REF-1)
(CAR (PROGN (PRINC "2") REF2))))
Under this proposal, this would be required to print 12 and not 21.
(LET (X)
(PUSH (SETQ X (LIST 'A))
(CAR (SETQ X (LIST 'B))))
X)
; the PUSH first evalutes (SETQ X (LIST 'A)) => (A)
; then evaluates (SETQ X (LIST 'B)) => (B)
; then modifies the CAR of (this latest value) to be ((A) . B).
; The result is (((A) . B)).
Documentation impact:
PUSH should more appropriately be described as:
"(PUSH Item Place) is roughly equivalent to (SETF Place (CONS Item Place))
except that the subforms of Place are evaluated only once, and Item is evaluated
before Place."
The phase "subforms of the reference" which appears several times in CLtL should
be made more specific to be "subforms of the macro call," referring to the
entire form that calls the generalized-variable manipulating macro.
Rationale:
This is the unstated intention of the page 97-100 discussion of
generalized-variable referencing macros, and indeed the intended definition of
"obvious semantics" for all macros.
Current practice:
Many implementations do not currently follow this evaluation order. In the form
(PUSH Item Place), Lucid, Franz, Kyoto and Xerox evaluate Place then Item.
Symbolics evaluates Item then Place.
For example, in Franz:
(macroexpand '(push (ref1) (car (ref2))))
(LET* ((#:G8 (REF2))
(#:G7 (CONS (REF1) (CAR #:G8))))
(EXCL::.INV-CAR #:G8 #:G7))
In Symbolics Common Lisp, it returns:
(LET* ((#:G5 (REF1))
(#:G4 (REF2)))
NIL
(SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4)))))
Cost to implementors:
Minimal, PUSH etc. could simply be defined by the appropriate macros.
Cost to users:
No currently portable program should be affected. However, this is a minor
incompatible change for some implementations. No serious performance impact is
expected; while some macro expansions may appear to be more verbose, most
compilers deal reasonably with the required order of evaluation.
Benefits:
The implementation and semantics of PUSH become more well specified. This
removes a source of non-portability, abeit likely rare.
Esthetics:
Common Lisp defines order of evaluation as left-to-right; this clarification
ensures consistency across the language.
Discussion:
This seems to be the intent of most of the relevant language in CLtL.
For example, the second to last paragraph on page 99
"As an example of these semantic rules, in the generalized-variable reference
(setf reference value), the value form must be evaluated after all the subforms
of the reference because the value form appears to the right of them."
makes it clear that in this context the phrase "generalized-variable reference"
was meant to refer to the entire macro call, not just the Place, and that order
of evaluation rules are not limited to subforms of Places. We hope the
specification should adopt more consistent terminology.
Note that DEFINE-SETF-METHOD is immune to the exception specified about DEFMACRO
and DEFINE-SETF-METHOD, because since CLtL p.103 says about DEFINE-SETF-METHOD:
"This binding permits the body forms to be written without regard for
order-of-evaluation issues."
∂14-Feb-88 1352 X3J13-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:51:55 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:49:20 PST
Date: 14 Feb 88 13:49 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-134920-1443@Xerox>
This issue is new.
!
Issue: REDUCE-ARGUMENT-EXTRACTION
References: REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut structure (pp. 312-313)
Category: ADDITION
Edit history: Version 1 by Pierson 5-Dec-87
Version 2 by Pierson 30-Dec-87
Version 3 by Masinter 13-Feb-88
Problem description:
REDUCE is the only one of the Common Lisp functions that modify or
search lists and sequences which does not accept a :KEY argument.
This complicates many uses of REDUCE.
Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):
Change the definition of REDUCE to take a :KEY keyword described as
follows:
If a :KEY argument is supplied, its value must be a function of one
argument which will be used to extract the values to reduce. The :KEY
function will be applied exactly once to each element of the sequence
in the order implied by the reduction order but not to the value of
the :INITIAL-VALUE argument, if any.
Example:
Using REDUCE to obtain the total of the ages of the possibly empty
sequence of astronauts ASTROS, would currently require:
(REDUCE #'+ (MAP 'LIST #'PERSON-AGE ASTROS))
If this proposal is adopted, the same result could be obtained without
creating a new list by:
(REDUCE #'+ ASTROS :KEY #'PERSON-AGE)
Rationale:
This proposal makes many common situations where REDUCE would be useful
much less cumbersome.
Current practice:
We know of no implementation which currently supports this feature.
Cost to Implementors:
This will require most implementations to make a trivial modification
to REDUCE. Implementations which wish to use this as an opportunity to
further optimize compiled calls to REDUCE will have to undertake more
work (which would be much more difficult today).
Cost to Users:
None, this is an upward compatible extension.
Cost of non-Adoption:
REDUCE will continue to be more difficult to use than other sequence
functions on sequences of complex objects.
Benefits:
REDUCE will become easier to use on sequences of complex objects. It
will be easier for compilers to convert some calls to REDUCE into
efficient loops.
Aesthetics:
Slightly damaged in one way. All :KEY arguments are currently defined
to be used for predicates, this proposal will implicitly broaden :KEY
to support general extraction for any purpose.
Slightly improved in another way. Many common situations where REDUCE
could be used would be easier to write and easier to later read.
Discussion:
Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY. No one has objected
to this change in the recent round of discussions.
There is some controversy over whether the "definition" of :KEY
arguments on page 246 of CLtL really constitutes a definition or just
an "unwritten rule".
∂14-Feb-88 1341 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:40:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:41:10 PST
Date: 14 Feb 88 13:40 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-134110-1441@Xerox>
This issue was distributed at the November 1987 meeting.
!
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
Version 3, 4-Nov-87 Moon, small clarifications at KMP's urging
PROBLEM DESCRIPTION:
The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand. It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.
PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS):
Add to Common Lisp the concept of "setf functions". Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function. The name of this setf function
is a list (setf -name-), where -name- is a symbol. The body of this
function is surrounded by an implicit block named -name-.
The functions, macros, special forms, and declarations defined in CLtL
and listed in the References section above need to be enhanced to accept
such lists in addition to symbols as function names, so that setf
functions can be defined and manipulated.
A setf function receives the new value to be stored as its first
argument. Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function, as for any function, is retrieved by
(documentation '(setf foo) 'function).
Examples:
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(funcall #'(setf ,(car form))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a similar feature,
in that they allow setting functions named (SETF reader). We don't
know of any implementation that has precisely the proposed feature.
ADOPTION COST:
The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols. Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.
The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.
This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.
COST OF NON-ADOPTION:
Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System. Some major rethinking of CLOS would be
required.
BENEFITS:
Allow CLOS to be defined without out-of-hand complexity.
Improve usability of SETF.
CONVERSION COST:
None, this is an upward-compatible change.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new
feature, but otherwise they will still work.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
DISCUSSION:
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. This proposal does not attempt to
change that.
There was some concern about introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
However, the CLOS unsuccessfully tried a number of alternatives.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
This proposal is not incompatible with other extensions to function
specifications present in some implementations.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
d) Introduce a new name for SYMBOL-FUNCTION, since it accepts
non-symbols now.
e) Should one allow these extended function names in the car-position
of an expression to be evaluated? The extra complexity didn't seem
justified, instead, an explicit FUNCALL is required.
∂14-Feb-88 1354 X3J13-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:54:18 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:54:43 PST
Date: 14 Feb 88 13:54 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-135443-1454@Xerox>
This issue is new.
!
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261)
Issue REMF-DESTRUCTURING-UNSPECIFIED
(discussion of NREVERSE, NSUBSTITUTE)
Issue AREF-1D
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky
28-Apr-87, Version 2 by Pitman (variations on the theme)
26-Oct-87, Version 3 by Masinter (clean up for release)
11-Nov-87, Version 4 by Masinter (respond to comments)
5-Feb-88, Version 5 by Masinter
Description:
Common Lisp provides many useful operations on lists and vectors which don't
apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can REPLACE
the contents of one vector with another, but one can't do this for arrays. One
can verify that EVERY element of a vector has some property, but one can't do
this for arrays, and so on.
The programmer who wishes to use arrays instead of vectors must give up most of
the useful tools CLtL provides for manipulating sequences, even though there is
no intuitive reason why operations like FILL, REPLACE, and EVERY shouldn't work
on arrays.
Common Lisp already provides a facility called "displaced arrays" which can be
used to overlay one array on top of a portion of another, even if the two are of
different ranks, so that the two share storage or use the awkward convention of
creating a displaced array to the operand. However, creating a displaced array
merely to perform FILL, REPLACE or EVERY is awkward.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE):
1) Extend the definitions of sequence functions that either return their
argument sequences or return non-sequences so that they also allow arrays of
rank other than 1. These functions should treat array arguments as vectors
displaced to the array storage (in row-major format). The affected functions are
LENGTH, ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY, NOTEVERY, REDUCE,
SEARCH, MISMATCH, FILL, REPLACE, SORT.
For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42, and (ELT A
7) should return the same element as (AREF A 0 1 0). :START and :END keywords
would be interpreted relative to the vector, as would the results returned by
POSITION and SEARCH.
2) Extend the definitions of sequence functions whose result should be the same
shape as but not necessarily EQ to some argument. These functions should deal
with array arguments by returning an array of the same shape as the argument,
and operate on their argument in row-major order. The affected functions are
SUBSTITUTE, NSUBSTITUTE, REVERSE, NREVERSE, SUBSTITUTE-IF, NSUBSTITUTE-IF,
SUBSTITUTE-IF-NOT, NSUBSTITUTE-IF-NOT and MAP.
3) Sequence functions that modify the number of elements in the array remain
unchanged: it is an error to pass arrays of rank other than 1. (The functions
are not extended because the shape would be undefined.) The unaffected functions
are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE,
DELETE-DUPLICATES.
Note that EQUALP does -not- treat arrays as vectors. It is not a sequence
function, and it already has a well-defined behavior for arrays. To test whether
the arrays A and B, of different shapes, have the same elements, one might
write:
(AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)).
Rationale:
This is a useful upward compatible extension with relatively low adoption cost.
Cost to Implementors:
This would involve a lot of changes to functions, but all of the changes are
likely to be minor. The presence of displaced arrays in the language already
guarantees that the internal storage format needed to back up these proposed
changes is already in place.
Cost to Users:
This change is upward compatible; current user code should run unmodified.
Benefits:
This proposal adds natural support for multi-dimensional arrays. Currently,
users must write nested DO loops every time they want to perform an array
operation equivalent to FILL, REPLACE, REDUCE, etc., or else they build
displaced vectors by hand and pass them to the sequence functions when
necessary. With this proposal, users of arrays do not have to use home-grown
utilities to duplicate functionality already primitively provided to users of
arrays. The sequence functions become useful in a variety of new situations.
Aesthetics:
This proposal extends sequence functions to cover arrays while neatly avoiding
the temptation to turn Common Lisp into a half-baked APL. Instead of trying to
provide a full set of array handling primitives (which would be needed to take
arbitrary k-dimensional slices out of n-dimensional arrays, or to apply an
operator across a specific dimension of a multidimensional array), it requires
just one rule:
treat arrays as displaced vectors where it is well-defined.
Current Practice:
We know of no current implementation of this proposal.
Discussion:
This issue was discussed by the cleanup committee at length; what follows is
only a brief summary of the discussion.
An alternative considered was to only affect those functions which didn't
explicitly depend on the shape of the array; that is, to modify COUNT, SOME,
EVERY, NOTANY, NOTEVERY, FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP, and
expressly forbid arrays as arguments to other sequence functions, including
LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH, MISMATCH, REVERSE, NREVERSE, SORT,
MAP, as well as SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES,
DELETE, DELETE-DUPLICATES. This would be less controversial, since it includes
only those functions which do not deal with positional information. Some hedging
over REDUCE and FIND, which often have non-positional uses, were considered.
Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE. He's been
building displaced vectors to pass to sequence functions when necessary and
really dislikes it.
We considered but discarded as unworkable an alternative where POSITION and FIND
might deal with "positions" as lists of array subscripts.
At one point, this proposal included an extension to COERCE to allow COERCE to
translate from array types to sequences, but it was thought better to separate
out COERCE. We considered a proposal to only introduce a change to COERCE, and
require users who want to operate on arrays explictly perform, e.g., (COUNT
item (COERCE x 'SEQUENCE)). This alternative would have the lowest adoption cost
but was deemed awkward.
Sequence functions like FILL and COUNT are already generalized to arrays in
non-Lisp contexts; in English we use the generalized forms all the time, e.g.,
"count the number of 1's in this matrix."
There is some concern that this proposal makes the requirement for row-major
ordering of internal storage for arrays even more evident. While such an
internal ordering is implied by the ability to create displaced arrays and the
AREF-1D proposal, this proposal adds yet another constraint.
The general reason for opposing this change is that it adds more mechanism than
it is worth. The general reason for liking it is that it adds generality at
little cost.
∂14-Feb-88 1408 X3J13-mailer
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:08:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:08:41 PST
Date: 14 Feb 88 14:08 PST
From: Masinter.pa@Xerox.COM
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-140841-1482@Xerox>
This issue had not been distributed before.
!
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE
References: #+ (p. 358), #- (p. 359), *FEATURES* (p. 448)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 01-Mar-87
Version 2 by Masinter 10-Nov-87
Version 3 by Masinter 14-Nov-87
Problem Description:
No information is provided in the description of #+ and #- (pp. 358-359) about
what package the features are read on.
In some systems, the current package is used. Since there is no wording in CLtL
to the contrary, it's reasonable to assume that this would be done, but a
consequence of this is that you must be much more sensitive to the package
you're in at any given time when using #+ or #- even for system-provided
features. (This is a problem if the LISP package can contain only the symbols in
CLtL because system-provided features will likely not have the names of symbols
on LISP and hence will require package prefixes. Having a symbol named
LISP:SYMBOLICS or LISP:LUCID would not be possible, so something like
#+Symbolics would not be possible; you'd have to write #+SYSTEM:SYMBOLICS or
some such, which might get a read error in a non-Symbolics implementation that
didn't export SYMBOLICS from SYSTEM...)
In some systems, a canonical package (such as KEYWORD) is used. This means that
package prefixes are rarely necessary in sharpsign conditionals for
system-provided features regardless of the current package or restrictions about
what may be in LISP. (For example, the KEYWORD package can have any symbol so
it's not a problem to push :SYMBOLICS or :LUCID on *FEATURES*).
This has implications about what goes on the *FEATURES* list (p. 448).
Proposal (SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD):
Specify that the default package while reading feature specs is the keyword
package. Other packages may be designated by use of explicit package prefixes.
Symbols on *FEATURES* may be in any package but that in practice they will
mostly be on the keyword package because that's the package #+/#- uses by
default. If symbols in a package other than keyword appear on *FEATURES*, they
will be seen by #+/#- only if marked by explicit package prefixes in the
written feature-spec.
Clarify that the package of the IEEE-FLOATING-POINT symbol mentioned on p. 448
is KEYWORD.
Rationale:
Making the behavior of #+ and #- well defined is important for people writing
portable code that manipulate *FEATURES* directly.
Current Practice:
Some implementations bind *PACKAGE* while reading feature specs and others do
not.
Adoption Cost:
Changes to implementations to make them conform should be fairly minor if not
trivial.
Benefits:
As currently specified, using #+ and #- in truly portable code can have
bootstrapping problems, since it is sometimes required to conditionally set up
*FEATURES* in different ways for different systems.
Conversion Cost:
Few changes to user code will be required; code that uses #+ and #- will
continue to work, although code that manipulates *FEATURES* directly may require
editing.
Aesthetics:
Most users would perceive this as a bug fix either to CLtL or to certain
implementations.
Discussion:
The cleanup committee supports this proposal.
It might be reasonable to suggest that only vendors should add keyword symbols
to the *FEATURES* list, and that users should add features on their personal
packages so that collisions due to user applications were less likely. This idea
might be a subject of controversy though, so is not part of this proposal.
It would be useful to create a non-binding registry of feature names (and
package names) already in use, so that Lisp implementors could pick otherwise
unused feature names, and users who wanted to write portable code could know
what feature names were preferred.
∂14-Feb-88 1406 X3J13-mailer Issue: SHADOW-ALREADY-PRESENT (version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:05:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:04:22 PST
Date: 14 Feb 88 14:03 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SHADOW-ALREADY-PRESENT (version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-140422-1472@Xerox>
This issue is new.
!
Issue: SHADOW-ALREADY-PRESENT
References: CLtL p.186
Category: CLARIFICATION/CHANGE
Edit history: Version 1 Moon 24 Aug 87
Version 2 Moon 27 Aug 87 incorporate JonL's suggestions
Version 3 Masinter 26-Oct-87
Version 4 Masinter 10-Nov-87
Problem description:
The description of the SHADOW function can be interpreted as saying that the
function has no effect, if the symbol is already present in the package. This
happens if the third sentence in the description ("then nothing is done") is
interpreted as applying to the entire description rather than just to the fourth
sentence.
SHADOW is said to take symbols as arguments, however only the print-name is
meaningful for this operation (that fact is already documented).
Proposal SHADOW-ALREADY-PRESENT:WORKS:
1) The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
list, even when the symbol is already present in the package.
2) The first argument to SHADOW is allowed to be or contain strings as well as
symbols. The specification "the print name of each symbol is extracted" is to be
modified accordingly.
Test Case:
;;; SHADOW always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
;;; list of a package
(make-package 'test-1)
(intern "TEST" (find-package 'test-1))
(shadow 'test-1::test (find-package 'test-1))
(assert (not (null (member 'test-1::test (package-shadowing-symbols
(find-package 'test-1))))))
(make-package 'test-2)
(intern "TEST" (find-package 'test-2))
(export 'test-2::test (find-package 'test-2))
(use-package 'test-2 (find-package 'test-1)) ;should not error
;;; To test the use of strings in place of symbols
;;; change the third line of the test case to
;;; (shadow "TEST" (find-package 'test-1))
;;; Note the use of capital letters in the string.
Rationale:
CLtL p. 180 describes a name conflict problem that can occur when calling the
function USE-PACKAGE. The name conflict is between a symbol directly present in
the using package and an external symbol of the used package. This name conflict
may be resolved in favor of the symbol directly present in the using package by
making it a shadowing symbol. For this to work, SHADOW must add the symbol to
the PACKAGE-SHADOWING-SYMBOLS list even when it is already present in the
package.
Since only the print name of a symbol argument is meaningful, a string should
also be accepted. This is particularly useful to avoid problems when compiling
code in one package environment and loading it into a slightly different package
environment, where the symbol that was referred to at compile time may not be
present at load time. This is particularly important because the symbol
referred to by the print name may be changed by evaluation of the SHADOW form.
A close reading of CLtL shows that one can already use (shadow '#:bar) in place
of (shadow 'bar), to achieve much the same effect as (shadow "BAR"). But the
user should not have to play such games, strings should be accepted.
Current practice:
Symbolics and Spice Lisp add the symbol to the PACKAGE-SHADOWING-SYMBOLS list,
even when the symbol is already present in the package. Kyoto Common Lisp,
Lucid Common Lisp, and Xerox Common Lisp ignore SHADOW when the symbol is
already present in the package. It seems likely that we will find several
implementations in each camp.
SHADOW accepts strings in Symbolics Common Lisp.
Cost to implementors:
This should be a minor change to implementations that do not currently work this
way.
Cost to users:
Technically this would be an incompatible change to implementations that do not
already behave as proposed, however it is difficult to conceive of a user
program that would require any conversion to cope with the change. Some users
might want to remove kludges that were only necessary to get around the former
misbehavior of SHADOW.
Cost of non-adoption:
Inconsistency among implementations and lack of a clear way to resolve the name
conflict mentioned in Rationale.
Benefits:
Consistency among implementations and fewer mysterious package problems.
Esthetics:
The proposal would remove an unnecessary special case, thus simplifying the
language slightly.
Discussion:
The issue was raised by Dieter Kolb on the Common-Lisp mailing list.
It would be useless for SHADOW to fail to put a symbol that is already present
in the package onto the PACKAGE-SHADOWING-SYMBOLS list. Moon believes CLtL
intended to describe what is being proposed, but unfortunately used ambiguous
language.
The cleanup committee endorses this proposal.
∂14-Feb-88 1455 X3J13-mailer Common Lisp cleanup issue status to X3J13
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:54:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:55:15 PST
Date: 14 Feb 88 14:54 PST
From: Masinter.pa@Xerox.COM
Subject: Common Lisp cleanup issue status to X3J13
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-145515-1510@Xerox>
!
This is the list of issues distributed for the March 1988 X3J13 meeting:
- ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87)
(Interaction of ADJUST-ARRAY and displaced arrays)
- APPEND-DOTTED (Version 5, 14-Jan-88)
(What happens to CDR of last CONS? in other
than last arg?)
- AREF-1D (Version 7, 14-Nov-87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed X3J13/Jun87
Version 7 passed X3j13/Nov87
- ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87)
(Extend ASSOC-IF, etc. to allow :KEY)
- COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Version 1 passed X3J13/Nov87
- COMPILER-WARNING-BREAK (Version 4,23-Nov-87 )
(Does *BREAK-ON-WARNING* affect the compiler?)
- DECLARE-MACROS (Version 3, 5-FEB-88)
(Disallow macros expanding into declarations.)
- DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87)
(Documentation string is not evaluated.)
- DISASSEMBLE-SIDE-EFFECT (version 3, 21 Jan 88)
(DISASSEMBLE doesn't smash the def if not compiled)
- DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87)
( DO-SYMBOLS can the same symbol twice?)
- DRIBBLE-TECHNIQUE (Version 2, 14-Feb-88)
(dribble can't be used programmatically)
- FLET-DECLARATION (Version 2, 2 Feb 88)
(Allow declarations in FLET, MACROLET)
- FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(paramerize number of digits between commas)
Version 2 passed X3J13/Nov87
- FORMAT-COLON-UPARROW-SCOPE (Version 3, 5 Feb 88)
(what iteration does ~:↑ exit from?)
- FUNCTION-TYPE-KEY-NAME (Version 3, 5 Feb 88)
(allow &KEY (:KEYNAME type)) in FUNCTION decls )
- FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3, 13-Feb-88)
(allow &rest <type> in function types to refer to element
type)
- FUNCTION-TYPE (Version 9, 13-Feb-88)
(Change definition of FUNCTIONP, function type ...)
- GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 passed X3J13/Nov87.
- KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
(&KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Version 8 passed X3J13/Nov87
- PATHNAME-STREAM (Version 6, 14-Nov-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Version 6 passed X3J13/Nov 87
- PATHNAME-SYMBOL (Version 5, 5-Feb-88)
(Do symbols automaticly coerce to pathnames?)
- PUSH-EVALUATION-ORDER (Version 5,25-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
- REDUCE-ARGUMENT-EXTRACTION (version 3, 13-Feb-88)
(Add :KEY to REDUCE)
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
(Allow (DEFUN (SETF FOO) ..))
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5, 5-Feb-88)
(let FIND, SUBSTITUTE etc work on multi-dimensional arrays)
- SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
(What does SHADOW do if symbol is already there?)
- SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87)
(*FEATURES* are in the keyword package)
!
The following issues were mailed prior to the June 1987 meeting and passed at
that meeting; they will not be distributed again except by request.
- COMPILER-WARNING-STREAM (Version 6, 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87
- DEFVAR-INIT-TIME (Version 2, 29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
- DEFVAR-INITIALIZATION (Version 4, Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13, Jun87.
- FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
- FORMAT-ATSIGN-COLON (Version 4, 5-jun-87)
(@: == :@ in format)
Version 4 passed X3J13/Jun87.
- FORMAT-OP-C (Version 5, 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
- IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
- PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
!
For your information only, the following issues are still under consideration by
the cleanup committee. Volunteers to help out with the preparation of issue
writeups are welcome. If you would like to review the mail discussion on a given
topic, please let me know and I will forward it to you.
- ADJUST-ARRAY-FILL-POINTER
(Interaction of Adjust-ARRAY and fill pointers.)
Need volunteer to write up.
- CONSTANT-SIDE-EFFECTS (not yet submitted)
(It is an error to do destructive operations on constants in code,
defconstant.)
Discussed 12/86 - 1/87
Will take on if no compiler proposal
- DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted)
(Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be
required to be disjoint from other types?)
From CLOS committee, not yet submitted
- DECLARATION-SCOPE (Version 2, 2-Feb-88)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
- DECLARE-TYPE-EXACT (from Kempf as EXACT-CLASS)
(Want to be able to declare (EQ (TYPE-OF X) 'Y), i.e.,
not a subclass.)
Useful after CLOS
- DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted)
What is the lexical environment of DEFTYPE, DEFINE-SETF bodies?
Mail 11-12 Oct 87 on common-lisp
Interacts with compiler proposal?
- DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- EQUAL-STRUCTURE (not yet submitted)
(Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.)
What do EQUAL EQUALP and friends do
on structures?
(Need volunteer.
ALarson@HI-MULTICS.Arpa, edsel!jonl@labrea.stanford.edu,
Okuno@SUMEX-AIM.STANFORD.EDU, goldman@vaxa.isi.EDU?)
- FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just
an open file-stream. Let it take a keyword argument :ELEMENT-TYPE,
defaulting to STRING-CHAR for non-stream arguments and to the
element-type of the stream for a stream argument."
Need volunteer to write up.
- FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no formal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date
ambiguity until we are at the point where we can make proposals
that discuss signalling named conditions. "
Need volunteer.
- FORMAT-NEGATIVE-PARAMETERS (mail 19 May 87, no formal proposal)
"format parameters are assumed to be non-negative integers except
as specifically stated"
Need volunteer.
- FUNCTION-ARGUMENT-TYPE-SEMANTICS (not yet submitted)
(Change semantics of argument types in function declarations.)
- FUNCTION-SPECS (not yet submitted)
(add "function specs" for defun, trace etc)
beyond SETF-FUNCTION-VS-MACRO.
(SMH!franz@ucbarpa.berkeley.edu, JonL, RWK)
- GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
- LAST-N (version 1, 4-DEC-87)
(Extend LAST to take an optional N)
Needs rewrite as per Moon
- LISP-SYMBOL-REDEFINITION (no formal proposal yet)
Is it legal to redefine symbols in the LISP package?
Mail 14-Aug-87
Merge with SPECIAL-FORM-SHADOW
Needs volunteer
- LOAD-TIME-EVAL (Versin 4, 2 Feb 88)
(evaluation when compiled file is loaded)
- MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
re-extracted from ENVIRONMENT-ARGUMENTS
CLOS committee to submit?
- PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87)
How to deal with subdirectory structures in pathname functions?
make :DIRECTORY a list?
Need volunteer to rewrite.
- PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
Mail Aug 87 discussion
How to deal with logical devices, :unspecific components, etc
in pathname functions
RWK@YUKON.SCRC.Symbolics.COM may submit proposal.
- PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87)
(interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM)
"Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal
interaction must or even ought to work."
- PROCLAIM-LEXICAL (Version 5, 14-Nov-87)
(add LEXICAL, GLOBAL, CONSTANT proclaimation)
some serious problems
- PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
- REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 )
(Specification of side-effect behavior in CL)
DEFINED, VAGUE and IN-BETWEEN
- REMF-MULTIPLE (Version 1, 26 Jan 88)
(What does REMF do if it sees more than one INDICATOR?)
- REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87)
(where does REQUIRE look for files?)
- REST-LIST-ALLOCATION (not yet submitted)
(APPLY #'LIST X) == (COPY-LIST X)?
need volunteer
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
- SETF-SUB-METHODS (version 1, 12-Feb-88)
(more careful definition of order of evaluation
inside (SETF (GETF ...) ...) )
- SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Mild disagreement: it is an error?
- SPECIAL-FORM-SHADOW (no formal proposal)
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
- SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Forwarded to character committee.
- STANDARD-INPUT-INITIAL-BINDING (Version 1, 19 Jan 88)
Move text of Test case/Example to Problem description.
Somewhere between completely undefining and current situation is
wanted.
- STREAM-CLASS-ACCESS (No formal proposal)
(Originally FOLLOW-SYNONYM-STREAM 19-DEC-86)
Define stream accessors as if synonym-stream two-way-stream etc
were CLOS classes?
Need volunteer
- STRUCTURE-DEFINITION-ACCESS (No formal proposal)
(access to slot accessors for DEFSTRUCT etc.)
Need volunteer to write up
- SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any
:START or :END argument have a negative index or point past the end
of the sequence in question. (With respect to whether signalling is
required, this error will be treated the same as array
out-of-bounds.)"
Need volunteer to write up
- TAILP-NIL (no formal proposal yet)
(Operation of TAILP given NIL)
Needs writeup in current format.
- TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87)
(Allow trace for SETF functions, macros, etc.)
Environment extension?
- UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87)
(What happens with non-local exits out of UNWIND-PROTECT
cleanup clauses?)
- VECTOR-PUSH-EXTEND-DEFAULT (no proposal yet)
CLtL says that vectors are extended by a "reasonable" amount. What's that?
∂16-Feb-88 1045 X3J13-mailer March 1988 agenda questions
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 10:45:00 PST
Received: by labrea.Stanford.EDU; Tue, 16 Feb 88 10:45:09 PST
Received: from sunvalleymall.lucid.com by edsel id AA03090g; Tue, 16 Feb 88 10:16:15 PST
Received: by sunvalleymall id AA28197g; Tue, 16 Feb 88 10:21:23 PST
Date: Tue, 16 Feb 88 10:21:23 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802161821.AA28197@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: March 1988 agenda questions
I would like to prepare the agenda next week.
If you have something that should be discussed or voted on at the
March meeting please let me know what it is, the Document number
(if any) and approximate time needed.
Thanks!
---jan---
∂16-Feb-88 2122 X3J13-mailer March 1988 agenda questions
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 21:22:35 PST
Received: by labrea.Stanford.EDU; Tue, 16 Feb 88 21:21:45 PST
Received: from bhopal.lucid.com by edsel id AA05999g; Tue, 16 Feb 88 21:07:02 PST
Received: by bhopal id AA02339g; Tue, 16 Feb 88 21:12:15 PST
Date: Tue, 16 Feb 88 21:12:15 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802170512.AA02339@bhopal.lucid.com>
To: edsel!jlz@labrea.Stanford.EDU
Cc: x3J13@sail.Stanford.EDU
In-Reply-To: Jan Zubkoff's message of Tue, 16 Feb 88 10:21:23 PST <8802161821.AA28197@sunvalleymall.lucid.com>
Subject: March 1988 agenda questions
The four of us -- smh, rwk, jonl, and rg -- have an issue that needs more
time than a few minutes of cleanup committee covering: the extension of
names for definitions (sometimes referred to as "function specs"). Steve
(Haflich) has the problem description and issues written down, and Bob
(Kerns) has a proposed implementation. It would probably take 10 minutes
to present the issue, and conceivably would be met by 5-20 minutes of
unmitigated flaming from the floor after it is presented.
-- JonL --
∂23-Feb-88 1308 X3J13-mailer Re: voting
Received: from mitre.arpa by SAIL.Stanford.EDU with TCP; 23 Feb 88 13:06:28 PST
Full-Name: Jim Antonisse
Message-Id: <8802232059.AA18904@mitre.arpa>
Organization: The MITRE Corp., Washington, D.C.
To: MATHIS@A.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU, jima@mitre.arpa
Subject: Re: voting
In-Reply-To: Your message of 26 Jan 88 14:06:00 -0500.
<[A.ISI.EDU]26-Jan-88 14:06:48.MATHIS>
Date: Tue, 23 Feb 88 15:59:23 EST
From: jima@mitre.arpa
Bob,
Where exactly *is* the March X3j13 meeting? Does anyone
have details of location, registration fee, etc., figured
out yet? I'll be travelling for the week before it so I'd
like to make all arrangements soon.
Thanks,
Jim Antonisse
MITRE
∂23-Feb-88 1541 X3J13-mailer voting
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 15:37:54 PST
Received: by labrea.Stanford.EDU; Tue, 23 Feb 88 14:57:40 PST
Received: from sunvalleymall.lucid.com by edsel id AA17257g; Tue, 23 Feb 88 14:09:49 PST
Received: by sunvalleymall id AA15130g; Tue, 23 Feb 88 14:15:41 PST
Date: Tue, 23 Feb 88 14:15:41 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802232215.AA15130@sunvalleymall.lucid.com>
To: jima@mitre.arpa
Cc: MATHIS@a.isi.edu, x3j13@sail.stanford.edu, jima@mitre.arpa,
edsel!jlz@labrea.Stanford.EDU
In-Reply-To: jima@mitre.arpa's message of Tue, 23 Feb 88 15:59:23 EST <8802232059.AA18904@mitre.arpa>
Subject: voting
I sent the original message on December 14 but it looks like it's time for
a reminder. Agenda, subcommitte meeting (that I have arranged) and voting
list to follow later this week.
---jan---
X3J13 Meeting and Subcommitte meetings
3/14/88 - 3/18/88
Palo Alto, CA
The next meeting of X3J13 will be held from 9:00am, Wednesday, March 16,
1988 until 5:00pm, Thursday, March 17, 1988, at the Hyatt Rickeys in Palo
Alto, CA. The meeting will be held in the Executive Conference Room.
Subcommittee meetings will be held Monday, March 14, Tuesday, March 15 and
Friday, March 18.
Please let me know if and when your subcommittee will be meeting in Palo
Alto in March. I need to reserve small rooms now if they're necessary. In
the interest of saving money, if you have a subcommittee member who is local
perhaps the meeting could be held at their company.
For example: the CLOS subcommittee will meet at Lucid
Monday, 3/14 and Tuesday 3/15 at 10:00. Friday's time is
yet to be determined.
A block of rooms is available at the Hyatt Rickeys. The rate will be $84 a
night (plus tax). A limited number of rooms are available for non-smokers.
Please call (800) 228-9000 or (415) 493-8000 before February 26 to receive
the discounted rate. Be sure to mention "X3J13 Standards Committee".
Before I call and get special airline fares I'd like to know if anyone has
found this to be useful. If I get no replies I'll assume it's not necessary
to set up special fares.
Refreshments will be available during the morning (8:00am) and afternoon
sessions. Lunch will be available Wednesday, March 16 and Thursday, March
17. If you have dietary restrictions please complete the appropriate
section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
I will be happy to arrange a group dinner for Wednesday, March 16. Someone
has suggested we go to Watercourse Way in Palo Alto for sushi dinner and go
hot tubbing afterwards at (combined fee of around $25) If interested, please
note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
|X Hyatt Rickeys |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
San Jose Airport
!
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rush hour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-8000. Hertz, Avis and National car rentals are
within 1 block.
Directions from San Jose airport: Take 101 north to San Antonio Road (about
15 minutes in non-rushhour traffic). Take San Antonio Road exit marked Los
Altos, heading toward the hills. Turn right on El Camino Real. The hotel
is on the right at 4219 El Camino Real, Palo Alto, CA 94306 (415) 493-8000.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@labrea.stanford.edu
(415) 329-8400
!
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
*Feel free to bring check to meeting but please let me know if you will be
attending.
!
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Lunch 3/18: yes _______ no _______
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Sushi Dinner 3/16: yes ______ something else ______
Hot tubbing 3/16: yes ______ something else ______
Set up special airline fares: yes _______ no _______
Subcommittee Name: _________________________________________________
Subcommittee Chair: ________________________________________________
____ We need a meeting room
____ We will be meeting at _________________________________________
∂24-Feb-88 1139 X3J13-mailer X3J13 committee meeting agenda draft
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:39:49 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:24 PST
Received: from sunvalleymall.lucid.com by edsel id AA21834g; Wed, 24 Feb 88 10:49:37 PST
Received: by sunvalleymall id AA17034g; Wed, 24 Feb 88 10:55:36 PST
Date: Wed, 24 Feb 88 10:55:36 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802241855.AA17034@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: X3J13 committee meeting agenda draft
DRAFT
X3J13 Committee Meeting Agenda
March 16 - 17, 1988
1 Call to Order, March 16, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis
- Introduction of attendees
- Report on ISO meeting, Dick Gabriel
- Future meetings and mailings, Jan Zubkoff
3 Approval of Agenda
4 Approval of Minutes
5 CLOS (Doc: 88-002, 88-003, 88-004), Dick Gabriel, Danny Bobrow, et.al.
6 Lunch, 12:00pm - 1:00pm
7 CLOS continuation
8 Recess, 5:00pm
9 Call to Order, March 17, 9:00am
10 Clean-up, Larry Masinter
11 Lunch
12 Status of Standard, Kathy Chapman; 1 hour
13 Function Specs, JonL White, Steve Haflich, Bob Kearns; 20 minutes
14 Condition System, Kent Pitman; 1 hour
15 Other committee reports
16 Adjournment, 5:00pm
∂24-Feb-88 1139 X3J13-mailer Subcommittee meetings
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:39:37 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:07 PST
Received: from sunvalleymall.lucid.com by edsel id AA21628g; Wed, 24 Feb 88 10:25:19 PST
Received: by sunvalleymall id AA16953g; Wed, 24 Feb 88 10:31:18 PST
Date: Wed, 24 Feb 88 10:31:18 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802241831.AA16953@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: Subcommittee meetings
Here are the ones I know about.
---jan---
Monday, 3/14
9:00 -
9:30 -
10:00 - CLOS
10:30 - Gabriel
11:00 - Lucid
11:30 - |
12:00 - |
12:30 - |
1:00 - | Characher
1:30 - | Linden
2:00 - | Hyatt Iteration
2:30 - | Delmonte Room White
3:00 - | | Hyatt
3:30 - | | Regency Room
4:00 - | - |
4:30 - | |
5:00 - - -
5:30 -
6:00 -
Tuesday, 3/15
9:00 - Character Clean-up
9:30 - Linden Masinter
10:00 - Hyatt | CLOS
10:30 - Delmonte Room | Gabriel
11:00 - | | Lucid
11:30 - | | |
12:00 - | - |
12:30 - | |
1:00 - | Editorial |
1:30 - | Chapman |
2:00 - | Lucid |
2:30 - | | |
3:00 - | - |
3:30 - | |
4:00 - - |
4:30 - |
5:00 - -
5:30 -
6:00 -
Friday, 3/18
9:00 -
9:30 -
10:00 -
10:30 -
11:00 -
11:30 -
12:00 -
12:30 -
1:00 -
1:30 -
2:00 -
2:30 -
3:00 -
3:30 -
4:00 -
4:30 -
5:00 -
5:30 -
6:00 -
∂24-Feb-88 1140 X3J13-mailer voting at X3J13
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:40:23 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:55 PST
Received: from sunvalleymall.lucid.com by edsel id AA22000g; Wed, 24 Feb 88 11:07:43 PST
Received: by sunvalleymall id AA17093g; Wed, 24 Feb 88 11:12:40 PST
Date: Wed, 24 Feb 88 11:12:40 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802241912.AA17093@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: voting at X3J13
X3J13 VOTING LIST for March 1988 meeting
Bob's records indicate these groups were represented at the
indicated meetings. If they have paid their X3 service fees,
they can vote at the meeting in Palo Alto.
Company Name Cambridge Ft. Collins
-----------------------------------------------------------
A.I. Architectures x
Aerospace x
Alliant x
Bath U. x x
CSC x
DEC x x
Edinbrugh U. x x
Encore x
Evans and Sutherland x
Franz x x
Gensym x
Gigamos x x
GMD x
Goldhill x x
Gould x
Grumman x x
Hewlett Packard x x
Honeywell x x
IBM x x
ILOG S.A. x
INRIA x
Internat. Lisp Assoc. x
Johnson Controls x x
Lucid x x
Mathis x x
MCC x x
Micro. Sys. Consultants x
MIT x
Mitre x x
NBS x
Prime x
Red Shark Software x
Schlumberger x
Sun x
Symbolics x x
Tektronics x x
Texas Instruments x x
Thinking Machines x x
Unisys x x
USC-ISI x
Wang x
Xerox x x
∂28-Feb-88 1147 X3J13-mailer ISO meeting news
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 11:47:20 PST
Date: 28 Feb 1988 14:46-EST
Sender: MATHIS@A.ISI.EDU
Subject: ISO meeting news
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]28-Feb-88 14:46:29.MATHIS>
Hot news from the ISO-IEC/JTC 1/SC 22/WG 16 Lisp meeting in Paris
February 24-25, 1988.
The working group decided "The draft standard to be provided by
the Working Group within 18 months will take as starting point
COMMON LISP (with X3J13 cleanups) with treatment of major issues
and default values to be identified (including issues in the
AFNOR list and on the agenda)." They also decided on "ISLISP" as
the working name of the standard language.
There is considerable hope in both X3J13 and this ISO working
group that the results of their work match exactly (this will
require close cooperation).
∂01-Mar-88 1445 X3J13-mailer X3 attendee list to date
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 14:45:14 PST
Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 14:06:55 PST
Received: from sunvalleymall.lucid.com by edsel id AA06854g; Tue, 1 Mar 88 13:56:26 PST
Received: by sunvalleymall id AA00420g; Tue, 1 Mar 88 14:02:49 PST
Date: Tue, 1 Mar 88 14:02:49 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8803012202.AA00420@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: X3 attendee list to date
Please let me know if your name isn't listed below and you are
attending the March meeting. I also need to know whether you
will be having lunch 3/16 and/or 3/17.
---jan---
Registration Fees
03/01/88
Name Company Paid
Masayuki Ida Aoyama Gakuin University -
Gregor Kiczales Xerox PARC -
Bob Mathis -0- -
Daniel Bobrow Xerox PARC y
Kathy Chapman Digital Equipment y
Steve Haflich Franz, Inc. y
Kevin Layer Franz, Inc. y
Thom Linden IBM y
Jeff Rininger SRI International y
Thomas Turba UNISYS Corp y
Walter van Roggen Digital Equipment y
Paul Beiser HP -
Eric Benson Lucid, Inc. -
Jeff Dalton University of Edinburgh -
Linda DeMichiel Lucid, Inc. -
Jerry Duggan HP -
Dick Gabriel Lucid, Inc. -
David Moon Symbolics, Inc. -
Julian Padget University of Bath -
Mary Van Deusen IBM Research -
JonL White Lucid, Inc. -
∂02-Mar-88 1203 Common-Lisp-mailer Request to be added to mailing list...
Received: from potomac.ads.com by SAIL.Stanford.EDU with TCP; 2 Mar 88 12:03:39 PST
Received: by potomac.ads.com (5.58/1.7)
id AA11771; Wed, 2 Mar 88 15:04:38 EST
Date: Wed, 2 Mar 88 15:04:38 EST
From: John T. Nelson <jtn%potomac@potomac.ads.com>
Message-Id: <8803022004.AA11771@potomac.ads.com>
To: ansi-common-request@potomac.ads.com, common-loops-request@potomac.ads.com,
common-windows-request@potomac.ads.com
Subject: Request to be added to mailing list...
We would like to be added to your mailing list. Sorry if I'm repeating
myself but we've had a few problems with ARPAnet. Please send the
common-windows, common-loops and ansi-common lists to their respective
addresses at our machine:
post-common-loops@potomac.ads.com
post-ansi-common@potomac.ads.com
post-common-windows@potomac.ads.com
Thanks.
John T. Nelson UUCP: sun!sundc!potomac!jtn
Advanced Decision Systems Internet: jtn@potomac.ads.com
1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611
Strange... and beautiful music
∂02-Mar-88 1350 X3J13-mailer Re: X3 attendee list to date
Received: from venera.isi.edu by SAIL.Stanford.EDU with TCP; 2 Mar 88 13:50:06 PST
Received: from isd1.isi.edu by venera.isi.edu (5.54/5.51)
id AA07388; Wed, 2 Mar 88 13:50:51 PST
Posted-Date: Wed 2 Mar 88 13:50:45-PST
Received: by isd1.isi.edu (5.54/5.51)
id AA09581; Wed, 2 Mar 88 13:50:49 PST
Date: Wed 2 Mar 88 13:50:45-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: X3 attendee list to date
To: edsel!jlz@labrea.stanford.edu
Cc: x3j13@sail.stanford.edu
Message-Id: <573342645.0.OHLANDER@VENERA.ISI.EDU>
In-Reply-To: <8803012202.AA00420@sunvalleymall.lucid.com>
Mail-System-Version: <SUN-MM(216)+TOPSLIB(128)@VENERA.ISI.EDU>
I will be attending the March meeting and will be having lunch on both
days. My registration and fee will follow shortly
Ron Ohlander
USC/ISI
-------
∂04-Mar-88 1440 X3J13-mailer X3J13 attendee list
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 14:40:12 PST
Received: by labrea.Stanford.EDU; Fri, 4 Mar 88 14:01:57 PST
Received: from sunvalleymall.lucid.com by edsel id AA22425g; Fri, 4 Mar 88 14:23:43 PST
Received: by sunvalleymall id AA03806g; Fri, 4 Mar 88 14:30:22 PST
Date: Fri, 4 Mar 88 14:30:22 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8803042230.AA03806@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu, paul%hpfclp@hplabs.hp.com
Subject: X3J13 attendee list
Please let me know if you have any additions/changes.
---jan---
X3J13 Attendee Information
03/04/88
Hot
Name Institute Paid L1 L2 Dinner Tub
David Bartley TI y y y - -
Paul Beiser HP - y y y -
Eric Benson Lucid, Inc. - - - y -
Daniel Bobrow Xerox PARC y y y y y
Kathy Chapman Digital Equipment y y y - -
Christopher Dabrowski NBS - y y - -
Jeff Dalton University of - y y y -
Linda DeMichiel Lucid, Inc. - - - y -
Jerry Duggan HP - y y - -
Dick Gabriel Lucid, Inc. - y y y -
Steve Haflich Franz, Inc. y - - - -
Masayuki Ida Aoyama Gakuin - y y y -
Sonya Keene Symbolics - y y - -
Gregor Kiczales Xerox PARC - y y y y
Kevin Layer Franz, Inc. y y y - -
Thom Linden IBM y - - y -
Larry Masinter Xerox PARC - y y - -
Bob Mathis -0- - y y y -
David Moon Symbolics, Inc. - y y - -
Ron Ohlander USC/ISI - y y - -
Julian Padget University of Bath - y y - -
Crispin Perdue Sun Microsystems - - - y -
Dan Pierson Encore y y y y y
Kent Pitman Symbolics - y y y -
Jeff Rininger SRI International y y y - y
Eiji Shiota Nihon Symbolics - y y y y
Guy Steele Thinking Machines, - y y y y
Thomas Turba UNISYS Corp y y y - m
Mary Van Deusen IBM Research - - - - -
Walter van Roggen Digital Equipment y y - y -
Ellen Waldrum TI - y y - -
JonL White Lucid, Inc. - - - y -
-------------------------------
10 25 24 17 6
∂07-Mar-88 1542 X3J13-mailer new and improved list
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 15:42:41 PST
Received: by labrea.Stanford.EDU; Mon, 7 Mar 88 15:43:20 PST
Received: from sunvalleymall.lucid.com by edsel id AA04874g; Mon, 7 Mar 88 14:59:33 PST
Received: by sunvalleymall id AA09200g; Mon, 7 Mar 88 15:06:23 PST
Date: Mon, 7 Mar 88 15:06:23 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8803072306.AA09200@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: new and improved list
X3J13 Attendee Information
03/05/88
Lunches Sushi Hot
Name Institute Paid 3/16 3/17 Dinner Tub
David Bartley TI y y y - -
Paul Beiser HP - y y y -
Eric Benson Lucid, Inc. - - - y -
Daniel Bobrow Xerox PARC y y y y y
Skona Brittian MSC y y y y y
Kathy Chapman Digital Equipment y y y - -
Pavel Curtis Xerox PARC - y y - -
Christopher National Bureau of - y y - -
Jeff Dalton University of - y y y -
Linda DeMichiel Lucid, Inc. - y y y -
Jerry Duggan HP - y y - -
Patrick Dussud TI - y y - -
Dick Gabriel Lucid, Inc. - y y y -
Richard Greenblatt Gigamos - y y - -
Steve Haflich Franz, Inc. y - - - -
Masayuki Ida Aoyama Gakuin - y y y -
Sonya Keene Symbolics - y y - -
Gregor Kiczales Xerox PARC - y y y y
Kevin Layer Franz, Inc. y y y - -
Thom Linden IBM y - - - -
Barry Margolin Thinking Machines - y y - -
Larry Masinter Xerox PARC - y y - -
Bob Mathis -0- - y y y -
David Moon Symbolics, Inc. - y y - -
Jim O'Dell Gigamos - y y - -
Ron Ohlander USC/ISI y y y y y
Julian Padget University of Bath - y y - -
Crispin Perdue Sun Microsystems - - - y -
Dan Pierson Encore y y y y y
Kent Pitman Symbolics - y y y -
Jeff Rininger SRI International y y y - y
Eiji Shiota Nihon Symbolics - y y y y
David Slater Computer Sciences - y y - -
Guy Steele Thinking Machines, y y y y y
Thomas Turba UNISYS Corp y y y - m
Mary Van Deusen IBM Research - - - - -
Walter van Roggen Digital Equipment y y - y -
Ellen Waldrum TI - y y - -
JonL White Lucid, Inc. - - - y -
∂08-Mar-88 1121 X3J13-mailer Re: X3J13 attendee list
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 8 Mar 88 11:21:23 PST
Received: from relay2.cs.net by RELAY.CS.NET id ae25704; 8 Mar 88 13:12 EST
Received: from csc.ti.com by RELAY.CS.NET id ak03153; 8 Mar 88 13:05 EST
Received: from home by tilde id AA09943; Tue, 8 Mar 88 10:43:52 CST
Received: by home id AA08325; Tue, 8 Mar 88 10:43:27 CST
Date: Tue, 8 Mar 88 10:43:27 CST
From: Ellen Waldrum <waldrum@home.csc.ti.com>
Message-Id: <8803081643.AA08325@home>
To: edsel!jlz@LABREA.STANFORD.EDU, paul%hpfclp@hplabs.hp.com,
x3j13@SAIL.STANFORD.EDU
Subject: Re: X3J13 attendee list
Jan,
I forgot. I will be going to dinner as well. BTW, David Bartley from TI
will be attending. I know he tried to send you a message.
-- Ellen
∂08-Mar-88 1339 X3J13-mailer X3 attendee list to date
Received: from HAL.CAD.MCC.COM ([128.62.1.126]) by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:38:22 PST
Date: Tue, 8 Mar 88 15:11 CST
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: X3 attendee list to date
To: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
cc: x3j13@sail.stanford.edu, Loeffler@MCC.COM
In-Reply-To: <8803012202.AA00420@sunvalleymall.lucid.com>
Message-ID: <19880308211108.3.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
Date: Tue, 1 Mar 88 14:02:49 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Please let me know if your name isn't listed below and you are
attending the March meeting. I also need to know whether you
will be having lunch 3/16 and/or 3/17.
Add:
David D. Loeffler MCC
I have made all my travel arrangements. I will be having lunch on 3/16
and 3/17. I will pay on Wednesday.
-- David D. Loeffler
∂19-Mar-88 1821 X3J13-mailer last meeting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 88 18:21:52 PST
Date: 19 Mar 1988 21:21-EST
Sender: MATHIS@A.ISI.EDU
Subject: last meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]19-Mar-88 21:21:18.MATHIS>
Thanks to all of you who participated in last week's meeting. I
think we had a very productive meeting. The results will be in
the minutes and reports from the various committees. The
committees are really working.
I have also noticed that some of you have already begun sending
out comments relative to last weeks discussions. Keep those
cards and letters coming.
Thanks, Bob
∂19-Mar-88 1844 X3J13-mailer minutes 3/88 mtg
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 88 18:44:21 PST
Date: 19 Mar 1988 21:43-EST
Sender: MATHIS@A.ISI.EDU
Subject: minutes 3/88 mtg
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]19-Mar-88 21:43:46.MATHIS>
Minutes of the X3J13 Meeting, Palo Alto, March 16, 17, 1988.
Wednesday, March 16
09:00 am Item 1, 2a, 2b., 3, 4.
Item 1. 2a. Call to Order. Bob Mathis
Item 2b. Introduction of attendees. Attendees list.
Item 4. Approval of minutes
Item 3. Approval of agenda.
Item 2d. Attendees were reminded to keep discussions short so that
entire agendas could be covered.
The method of distribution for backup will be netmail with
the following exceptions: documents which are too large for
netmail will be mailed, documents will be available in hard
copy at the meeting, and arrangements will attempt to be made
for those people requesting hard cover mailings.
Cambridge, June 13-17. Committee mtg Wed, Thur.
Washington, October, Committee mtg Wed, Thur.
Hawaii, Jan.
09:10 am. Item 2c.
Item 2c. Report on ISO meetings, Paris, Feb 24-25, 1988. Dick Gabriel.
Countries participating were: Canada, Commission of the
European Community, Denmark, France, Germany, Japan,
Netherlands, Switzerland, UK, and US. Position of each
country presented, demonstrating wide diversity of opinion.
US Delegation included Dick Gabriel (project editor), Bob
Mathis, Will Clinger (project editor), Patrick Dussud, Larry
Masinter, Kent Pitman, Thom Linden, and John McCarthy.
Votes were taken which Dick Gabriel stated to the ISO group
had to be tentative on his part since he wished to come back
to this group for advice.
1. Majority vote was to concentrate first on a short-term
standard.
2. Some characteristics of the standard, by preference:
portable, efficient, clear semantics and simple semantics.
3. Most popular departure points were Common Lisp, Scheme,
and Eulisp.
4. The majority vote was for the name ISLISP.
5. Responsibilities were distributed. US volunteered
documents, rather than volunteers, for OOP, Functions,
Macros, Multiprocessing, Character Set, Windows,
Conditions, Iteration. Bob Mathis emphasized to X3J13 that
individuals could volunteer.
10:30 am Break
10:45 am Item 5
Item 5 (Doc: 88-002, 88-003, 88-004), Guy Steele.
Chapter 1 and 2.
The purpose of having an implementation result being undefined
was shown to be that of having the result be undocumented so
that a user could not rely on the result (for example, use of
multiple ELSE in an IF).
JonL White expressed concern that the use of the name "symbol
class" would continue a direction, which he considered
misguided, on nomenclature on symbol-value. A broader
question was raised as one reply that CLOS committee could
not address the entire issue of nomenclature in Common Lisp.
Expressed concerns: voting on chapters 1 and 2 separate from
3; voting on chapters 1 and 2 without knowing how it fits
into CLTL; voting at this meeting rather than waiting until
reply from written comments integrated into chapters 1 and 2;
defining a continuing mechanism (ie. cleanup committee) for
continuing changes to chapters 1 and 2); defining a new
subcommittee to define the layering of Common Lisp.
12:10 pm Item 6 Lunch
1:00 pm Item 7 CLOS Continuation
The following motion was moved and unanimously passed:
X3J13 and the CLOS Subcommittee agree on the following:
1. X#J13 members will read and give comments on Document
88-002 (Chapters 1 and 2 of the CLOS Specification) by April
21, 1988. Comments can be sent via electronic mail to:
common-lisp-object-system@sail.stanford.edu
2. The CLOS Subcommittee will consider all comments, prepare
a revised draft of Chapters 1 and 2, and prepare a written
summary of how they addressed the comments. These documents
will be distributed to X3J13 members in advance of the June
X3J13 meeting.
3. At the June meeting, the X3J13 Committee will vote
whether or not to accept Chapters 1 and 2 out of the CLOS
Subcommittee.
Vote of thanks to the CLOS Subcommittee for their
work was moved and unanimously passed.
Chapter 3.
Gregor Kiczales presented a summary of the status of the
Metaobject Protocol (Chapter 3 of the CLOS Specification
88-003).
Moved by Barry Margolin, seconded by Dan Bobrow.
Approve the general direction of the Metaobject Protocol of
CLOS (as specified in 88-003), and recommend that the Object
Subcommittee continue working on this with an eye toward a
new draft prior to the fall meeting with the expectation that
we would then have a one month written comment period prior
to the winter meeting followed by a vote to move it out of
subcommittee at the winter meeting. Motion passed
unanimously by voice vote.
2:30 pm Afternoon break
2:40 pm Item 10
Item 10 Cleanup, Larry Masinter.
Moved and passed by voice vote 10-7: To postpone the vote on
the bundled cleanup issues until tomorrow morning.
Bundled Issues:
ADJUST_ARRAY_DISPLACEMENT
APPEND_DOTTED
AREF_1D
ASSOC_RASSOC_IF_KEY
COLON_NUMBER
DEFVAR_DOCUMENTATION
DISASSEMBLE_SIDE_EFFECT
DO_SYMBOLS_DUPLICATES
DRIBBLE_TECHNIQUE
FLET_DECLARATION
FORMAT_COMMA_INTERVAL
FORMAT_COLON_UPARROW_SCOPE
FUNCTION_TYPE_KEY_NAME
GET_SETF_METHOD_ENVIRONMENT
KEYWORD_ARGUMENT_NAME_PACKAGE
PATHNAME_STREAM
PATHNAME_SYMBOL
PUSH_EVALUATION_ORDER
REDUCE_ARGUMENT_EXTRACTION
SHADOW_ALREADY_PRESENT
SHARPSIGN_PLUS_MINUS_PACKAGE
Unbundled Issues to be separately considered:
COMPILER_WARNING_BREAK
DECLARE_MACROS
FUNCTION_TYPE_REST_LIST_ELEMENT
FUNCTION_TYPE
SETF_FUNCTION_VS_MACRO
SEQUENCE_FUNCTIONS_EXCLUDE_ARRAYS
Larry Masinter led a discussion of cleanup issues which were
not sent to members prior to this meeting. For back mail on
a particular issue, send to:
masinter.pa@xerox.com.
Otherwise, see:
cl-cleanup@sail.stanford.edu.
05:05 pm Item 8 Meeting adjourned
Thursday, March 17
09:00 am Item 9
Item 9 Call to Order. Bob Mathis
09:15 am Item 10
Item 10 Cleanup, Larry Masinter
Moved by Dave Slater and seconded by Dan Pierson that the
bundled cleanup issues be accepted in a single vote and
the unbundled cleanup issues be accepted on separate votes.
The motion passed by unanimous voice vote.
COMPILER_WARNING_BREAK - A majority voice vote and a majority
company vote rejected the addition of COMPILER_WARNING_BREAK.
DECLARE_MACROS - Cris Perdue moved and Dick Gabriel seconded
a motion to stop discussion of DECLARE_MACROS. The motion
was passed by majority company vote. A majority company vote
accepted the addition of DECLARE_MACROS.
FUNCTION_TYPE_REST_LIST_ELEMENT - JonL White moved and Barry
Margolin seconded to table the previous motion to accept
FUNCTION_TYPE_REST_LIST_ELEMENT. The motion passed by
company vote 16-7.
FUNCTION_TYPE - Unanimous straw vote showed a belief that
redefinition of some type was necessary (FUNCTION_TYPE).
Unanimous straw vote showed that some change was needed
rather than the status quo. Majority (all but 2) straw vote
showed sentiment was against the conservative proposal.
Majority straw vote passed to not accept 2E as written, but
rather to amend 2E so that FUNCALL and APPLY can accept
anything that can be coerced to a function. A straw vote by
company was called to accept 6B. The straw vote passed
(14-7-4). Barry Margolin moved and Jim Antonisse seconded to
table the previous motion to accept FUNCTION_TYPE and to ask
the subcommittee to resubmit FUNCTION_TYPE with changes in
line with the straw votes. The motion passed (20-1-3). Dick
Gabriel moved and Dan Pierson seconded that the conservative
proposal be immediately accepted. This was unanimously
rejected by company vote (0-25-0).
11:15 pm Break
11:30 pm General comments
SETF_FUNCTION_VS_MACRO - As agreed yesterday, this issue is
tabled until after the function specification report.
SEQUENCE_FUNCTIONS_EXCLUDE_ARRAYS - The motion to generalize
SEQUENCE_FUNCTIONS_EXCLUDE_ARRAYS passed (15-6-3). Dick
Gabriel moved and Dan Pierson seconded that the discussion be
reopened. The motion passed by majority company vote. David
Moon moved to call the question to a vote to generalize SEQ
... The vote was rejected (3-18-3).
12:15 pm Item 11 Lunch
01:15 pm Item 12
Item 12 Status of Standard, Kathy Chapman
After describing the phases of document preparation, concern
was expressed whether an early version of the document would
be available or whether the cost in time and money would make
an early version impractical. A straw vote unanimously
passed to require members wishing to review the document to
specifically ask for the document and pay for duplication and
mailing. Kathy has been asked for a more detailed plan for
distribution and review at the next meeting.
02:00 pm Status of Scheme Standard, David Bartley
Scheme standardization is under consideration in a
microprocessor group of IEEE. This umbrella is also working
toward the standardization of MODULA/2, SMALLTALK, FORTH,
and PILOT.
02:15 pm Item 15
Item 15 Other committee reports
MACRO SUBCOMMITTEE REPORT, Julian Padget
There has been no subcommittee meeting since the last X3J13
meeting. Two people responded to a request for interesting
macros. Julian reiterated his request and also asked for new
volunteers. Send any information to:
padget@maths.bath.ac.uk
CHARACTER SUBCOMMITTEE REPORT, Thom Linden
A detailed proposal was presented of the work done to date.
Several strawvotes presented moderate support for the
direction of parts of the proposal.
03:20 pm Break
03:30 pm Announcements, Bob Mathis
03:35 pm Item 15 (cont.)
Item 15 ITERATION SUBCOMMITTEE REPORT, Jon L. White
The status of LOOPS and the work being currently done in OSS
was described. Pavel Curtis discussed ITERATE and GATHERING.
Concern was expressed with the concept of the iteration
constructs being "portable, optional".
COMPILER SUBCOMMITTEE REPORT, Steve Haflich
Steve described a model to be used to figure out what a compile
file does.
04:35 pm Item 14
Item 14 Condition System, Andy Daniels
Comments have stopped so version 18 of proposal seems
stabilized. Open issues are still open but can be completed
as cleanup. Straw vote showed that the directions are right
and that the proposal should be presented for acceptance at
the June meeting. Volunteers are requested to flesh out
specification.
05:00 pm Item 13
Item 13 Function Specs, JonL White
JonL described the overview and goals of the specifications. A
proposal is forthcoming. Unanimous straw vote to encourage
the subcommittee to continue its work and to present a
proposal.
05:35 am Item 10 (cont.)
Item 10 Cleanup, Larry Masinter
SETF_FUNCTION_VS_MACRO - Unanimous straw vote showed that
discussion should be closed. Dan Pierson moved and Guy Steele
seconded the motion to table SETF... The motion passed by a
majority voice vote. Committee thanked Larry Masinter for
bringing forward these issues in such good condition and
Larry thanked his subcommittee.
06:00 Item Adjournment
Minutes submitted by Mary S. Van Deusen (March 17, 1988)
∂21-Apr-88 0708 X3J13-mailer X3J13 Meeting 6/13 - 6/17/88
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 07:08:00 PDT
Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 386470; Thu 21-Apr-88 10:07:49 EDT
Received: by scrc-pegasus id AA00636; Thu, 21 Apr 88 09:48:40 est
Date: Thu, 21 Apr 88 09:48:40 est
From: Rosemary Bouzane <bouzane@scrc-pegasus>
To: Symbolics@scrc-pegasus, x3j13@sail.stanford.edu
Subject: X3J13 Meeting 6/13 - 6/17/88
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at
The Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston,
∂21-Apr-88 0829 X3J13-mailer X3J13 Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 08:29:47 PDT
Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 386565; Thu 21-Apr-88 11:29:22 EDT
Received: by scrc-pegasus id AA01353; Thu, 21 Apr 88 11:19:00 est
Date: Thu, 21 Apr 88 11:19:00 est
From: Rosemary Bouzane <bouzane@scrc-pegasus>
To: Symbolics@scrc-pegasus, x3j13@sail.stanford.edu
Subject: X3J13 Meeting
Cc: bouzane@scrc-pegasus
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston, MA. The conference room location will be posted
on the marquis.
Please let me know if sub committee meetings are necessary so
conference room arrangements can be made. There is a possibility
that sub committees could use three (3) conference rooms at
Symbolics (one holds 15 people, the other two hold 10 people).
However, I would need to know as soon as possible how many sub
committee meetings there will be in a given day, how many people
in each meeting each day and what days. If Symbolics' conference
rooms are used this would reduce the individual cost.
A block of rooms have been put aside for our use at the
Guest Quarters Suite Hotel; the rate will be $140 for single
occupancy and $160 for double occupancy. Please call Reservations
at the Hotel (617) 783-0090 before May 12, 1988 to receive this rate.
Be sure to mention "X3J13 Standards Committee". A one night
deposit is required. All registered guests are offered a
complementary American Breakfast (this is a full breakfast) daily
in the Scullers Grille Restaurant (in the Hotel). In addition, all
registered guests are invited to attend the night manager's discount
cocktail reception at the Mezzanine Bar. Please note, if you choose
not to take advantage of these features, the breakfasts and receptions
are not refundable nor may they be substituted for any other meal or
function.
Refreshments will be available during the morning and afternoon sessions.
A deli lunch will be available on June 15 and 16 (assorted cold cuts,
potato salad, cole slaw, condiments, relishes, bread/rolls, coffee, tea,
soda, juices, fresh fruit) at the Hotel where the 15th and 16th's
meetings are being held. If any has a dietary restriction please
let me know.
The cost per person for food service and conference room rental is
$64.90. However, this will be reduced if the sub committee meetings
can be held at Symbolics. Only after everyone returns the registration
form will I be able to determine if the cost will remain at $64.90 or
if it will be reduced. A subsequent announcement will be sent with
regard to this once all forms are in and at that time a check will
be due.
Please let me know if you would like to schedule a group dinner,
suggestions are welcomed.
Also, if you wish, we are working with a national travel agent who
would be happy to help in acquiring lower faries by trying to
group people together. Please let me know your proposed travel
if you want to try our travel agent.
Directions from Logan Airport, Boston to the Guest Quarters Suite
Hotel:
The Guest Quarters Suite Hotel is located at the Allston/Cambridge
exit of the Massachusetts Turnpike, minutes from downtown Boston and
Cambridge. Since the Hotel does not offer a shuttle service your
best mode of transportation from the airport is by taxi. For your
convenience, some taxi rates are listed below.
From Logan Airport $12.20
From Local Bus Stations 8.00
From Train - South Station 7.00
X3J13 JUNE MEETING REGISTRATION FORM
Please mail to:
Rosemary Bouzane
Symbolics, Inc.
Eleven Cambrdige Center
Cambridge, MA 02142
(617) 621-7611
NAME:
INSTITUTION:
STREET ADDRESS:
CITY: STATE: PHONE:
NET ADDRESS:
SUBCOMMITTEE NAME:
NEED CONFERENCE ROOM FOR SUBCOMMITTEE MEETING:
DATE OF SUBCOMMITTEE MEETING:
NUMBER OF PEOPLE INVOLVED IN SUBCOMMITTEE MEETING:
WOULD LIKE A GROUP DINNER? YES NO
SUGGESTIONS:
TRAVEL ARRANGEMENTS:
PROPOSED DEPATURE FROM/DATE/TIME:
AIRLINE PREFERENCE
FREQUENT FLYER #:
PROPOSED RETURN TO/DATE/TIME:
∂21-Apr-88 0908 X3J13-mailer X3J13 Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 09:08:11 PDT
Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 386634; Thu 21-Apr-88 12:07:44 EDT
Received: by scrc-pegasus id AA01584; Thu, 21 Apr 88 11:38:19 est
Date: Thu, 21 Apr 88 11:38:19 est
From: Rosemary Bouzane <bouzane@scrc-pegasus>
To: Symbolics@scrc-pegasus, x3j13@sail.stanford.edu
Subject: X3J13 Meeting
Cc: bouzane@scrc-pegasus
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston, MA. The conference room location will be posted
on the marquis.
Please let me know if sub committee meetings are necessary so
conference room arrangements can be made. There is a possibility
that sub committees could use three (3) conference rooms at
Symbolics (one holds 15 people, the other two hold 10 people).
However, I would need to know as soon as possible how many sub
committee meetings there will be in a given day, how many people
in each meeting each day and what days. If Symbolics' conference
rooms are used this would reduce the individual cost.
A block of rooms have been put aside for our use at the
Guest Quarters Suite Hotel; the rate will be $140 for single
occupancy and $160 for double occupancy. Please call Reservations
at the Hotel (617) 783-0090 before May 12, 1988 to receive this rate.
Be sure to mention "X3J13 Standards Committee". A one night
deposit is required. All registered guests are offered a
complementary American Breakfast (this is a full breakfast) daily
in the Scullers Grille Restaurant (in the Hotel). In addition, all
registered guests are invited to attend the night manager's discount
cocktail reception at the Mezzanine Bar. Please note, if you choose
not to take advantage of these features, the breakfasts and receptions
are not refundable nor may they be substituted for any other meal or
function.
Refreshments will be available during the morning and afternoon sessions.
A deli lunch will be available on June 15 and 16 (assorted cold cuts,
potato salad, cole slaw, condiments, relishes, bread/rolls, coffee, tea,
soda, juices, fresh fruit) at the Hotel where the 15th and 16th's
meetings are being held. If anyone has a dietary restriction please
let me know.
The cost per person for food service and conference room rental is
$64.90. However, this will be reduced if the sub committee meetings
can be held at Symbolics. Only after everyone returns the registration
form will I be able to determine if the cost will remain at $64.90 or
if it will be reduced. A subsequent announcement will be sent with
regard to this once all forms are in and at that time a check will
be due.
Please let me know if you would like to schedule a group dinner,
suggestions are welcomed.
Also, if you wish, we are working with a national travel agent who
would be happy to help in acquiring lower fares by trying to
group people together. Please let me know your proposed travel
if you want to try our travel agent.
Directions from Logan Airport, Boston to the Guest Quarters Suite
Hotel:
The Guest Quarters Suite Hotel is located at the Allston/Cambridge
exit of the Massachusetts Turnpike, minutes from downtown Boston and
Cambridge. Since the Hotel does not offer a shuttle service your
best mode of transportation from the airport is by taxi. For your
convenience, some taxi rates are listed below.
From Logan Airport $12.20
From Local Bus Stations 8.00
From Train - South Station 7.00
Please feel free to contact me if you have any questions:
Rosemary Bouzane
Symbolics, Inc.
Eleven Cambridge Center
Cambridge, MA 02142
(617) 621-7611
Bouzane@SCRC.Symbolics.Com
X3J13 JUNE MEETING REGISTRATION FORM
Please mail to:
Rosemary Bouzane
Symbolics, Inc.
Eleven Cambrdige Center
Cambridge, MA 02142
(617) 621-7611
NAME:
INSTITUTION:
STREET ADDRESS:
CITY: STATE: PHONE:
NET ADDRESS:
SUBCOMMITTEE NAME:
NEED CONFERENCE ROOM FOR SUBCOMMITTEE MEETING:
DATE OF SUBCOMMITTEE MEETING:
NUMBER OF PEOPLE INVOLVED IN SUBCOMMITTEE MEETING:
WOULD LIKE A GROUP DINNER? YES NO
SUGGESTIONS:
TRAVEL ARRANGEMENTS:
PROPOSED DEPARTURE FROM/DATE/TIME:
AIRLINE PREFERENCE:
FREQUENT FLYER #:
PROPOSED RETURN TO/DATE/TIME:
∂21-Apr-88 1242 X3J13-mailer X3J13 Meeting
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 21 Apr 88 12:42:02 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 21 Apr 88 15:20:11 EDT
Received: by kali.think.com; Thu, 21 Apr 88 15:20:07 EDT
Date: Thu, 21 Apr 88 15:20:07 EDT
From: gls@Think.COM
Message-Id: <8804211920.AA20298@kali.think.com>
To: bouzane@scrc-pegasus.arpa
Cc: Symbolics@scrc-pegasus.arpa, x3j13@sail.stanford.edu,
bouzane@scrc-pegasus.arpa
In-Reply-To: Rosemary Bouzane's message of Thu, 21 Apr 88 11:19:00 est <8804211540.AA01439@Think.COM>
Subject: X3J13 Meeting
Date: Thu, 21 Apr 88 11:19:00 est
From: Rosemary Bouzane <bouzane@scrc-pegasus.arpa>
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston, MA. The conference room location will be posted
on the marquis.
I hope they use Scotch tape--thumbtacks in his chest will make him
scream with pain. :-)
(Actually, I *think* that's a typo, though "marquis" and "marquee"
do happen to be etymologically related.)
--The Pedantic Quux
∂21-Apr-88 1306 X3J13-mailer X3J13 Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 13:06:26 PDT
Received: from HARPAGORNIS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 387047; 21 Apr 88 16:05:18 EDT
Date: Thu, 21 Apr 88 16:04 EDT
From: Tom Parmenter <parmenter@STONY-BROOK.SCRC.Symbolics.COM>
Subject: X3J13 Meeting
To: gls@Think.COM, stupid@STONY-BROOK.SCRC.Symbolics.COM, bouzane@PEGASUS.SCRC.Symbolics.COM
cc: x3j13@sail.stanford.edu
In-Reply-To: <8804211920.AA20298@kali.think.com>
Message-ID: <19880421200448.3.PARMENTER@HARPAGORNIS.SCRC.Symbolics.COM>
Date: Thu, 21 Apr 88 15:20:07 EDT
From: gls@Think.COM
Date: Thu, 21 Apr 88 11:19:00 est
From: Rosemary Bouzane <bouzane@scrc-pegasus.arpa>
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston, MA. The conference room location will be posted
on the marquis.
I hope they use Scotch tape--thumbtacks in his chest will make him
scream with pain. :-)
(Actually, I *think* that's a typo, though "marquis" and "marquee"
do happen to be etymologically related.)
--The Pedantic Quux
Silly boy, it is the Marquis de Sade and he wanted it that way,
with the thumbtacks.
∂21-Apr-88 1352 X3J13-mailer X3J13 Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 13:52:18 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 387207; Thu 21-Apr-88 16:52:15 EDT
Date: Thu, 21 Apr 88 16:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: X3J13 Meeting
To: X3J13@SAIL.Stanford.EDU
cc: Symbolics@PEGASUS.SCRC.Symbolics.COM
In-Reply-To: <8804211920.AA20298@kali.think.com>,
<19880421200448.3.PARMENTER@HARPAGORNIS.SCRC.Symbolics.COM>
References: The message of 21 Apr 88 12:38 EDT from Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>,
The message of 21 Apr 88 12:19 EDT from Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>,
The message of 21 Apr 88 10:48 EDT from Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>,
The message of 21 Apr 88 12:19 EDT from Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>
Message-ID: <880421165144.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Rosemary Bouzane's inclusion of Symbolics@Pegasus in her messages about
the X3J13 meeting was not really appropriate since most of the recipients
on that list are not involved with X3J13. As such, I'm sure it would
be greatly appreciated by several hundred people if you would NOT cc
that address in any further replies to her message. Send your replies
only to
Bouzane@Pegasus.SCRC.Symbolics.COM
and/or X3J13@SAIL.Stanford.EDU
as appropriate. (And, of course, any replies to this message should
go just to me privately.) Thanks very much.
∂22-Apr-88 0114 X3J13-mailer X3J13 Meeting
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 22 Apr 88 01:14:33 PDT
Received: from en-c06.prime.com by RELAY.CS.NET id ab23998; 21 Apr 88 17:20 EDT
Received: from S51.Prime.COM by EN-C06.Prime.COM; 21 Apr 88 16:25:32 EDT
Received: from ENX.Prime.COM by S51.Prime.COM; 21 Apr 88 16:26:34 EDT
Received: from zaphod.prime.com by primerd.prime.com (3.2/SMI-3.0DEV3/smail)
id AA22731; Thu, 21 Apr 88 16:21:09 EDT
Received: by zaphod.prime.com (3.2/SMI-3.2)
id AA08727; Thu, 21 Apr 88 16:26:28 EDT
Date: Thu, 21 Apr 88 16:26:28 EDT
From: Douglas Rand <doug@zaphod.prime.com>
Message-Id: <8804212026.AA08727@zaphod.prime.com>
To: x3j13@SAIL.STANFORD.EDU
Subject: X3J13 Meeting
>> The next meeting of X3J13 will be held from 8:00 a.m., Monday,
>> June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
>> Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
>> in Boston, MA. The conference room location will be posted
>> on the marquis.
> I hope they use Scotch tape--thumbtacks in his chest will make him
> scream with pain. :-)
>
> (Actually, I *think* that's a typo, though "marquis" and "marquee"
> do happen to be etymologically related.)
I can't resist; since the meeting is in Boston (and with Guy's thumbtacks
to boot) does this make him the "Marquis De Scrod"?
Doug
∂25-Apr-88 1415 X3J13-mailer June Meeting addendum and varia
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Apr 88 14:15:35 PDT
Received: by labrea.Stanford.EDU; Mon, 25 Apr 88 14:15:19 PDT
Received: from sunvalleymall.lucid.com by edsel id AA05247g; Mon, 25 Apr 88 14:03:46 PDT
Received: by sunvalleymall id AA13882g; Mon, 25 Apr 88 14:05:18 PDT
Date: Mon, 25 Apr 88 14:05:18 PDT
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8804252105.AA13882@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: June Meeting addendum and varia
Meeting times for the June meeting:
6/13, 6/14 Monday and Tuesday Subcommittee meetings
6/15, 6/16 Wednesday and Thursday Committee Meeting 9:00 - 5:00
6/17 Friday Subcommittee meetings if necessary
Please let Rosemary know by this Friday, April 29 if you need a
room for a subcommittee meeting. Please let her know:
- name of subcommittee
- date needed
- starting and ending time
- approximately how many people will be attending
If she doesn't hear from you this week she will release the rooms.
We've set the fee for registration at $60.
***We are 2 weeks from subcommittee mailing time. Remember the
committee needs to have material in their hands 2 weeks before
the meeting or we can't legally vote.
***Looking ahead, I need a quick head count from those of you who
are seriously thinking about attending the joint X3J13/ISO
meeting in Hawaii in January. Please reply this week, I need to
book the hotel next week.
Thanks.
---jan---
Spring Meeting:
Where: Guest Quarters Suite Hotel
Sub Committee Meetings: 6/13 - 6/14, 6/17 if needed
Committee Meeting: 6/15 - 6/16
Contact: Rosemary Bouzane 617/621-7611
bouzane@scrc.symbolics.com
Fall Meeting:
Where: Contel, 12015 Lee Jackson Highway, Fairfax, VA
Subcommittee Mtgs: 10/10 - 10/11 in Contel Technical Center
Committee Meeting: 10/12 - 10/13 in Contel Auditorium
Contact: Bob Mathis 703/359-0203
mathis@b.isi.edu
Winter Meeting, Joint with ISO:
Where: Kauai, Hawaii
Subcommittee Meetings: 1/17 - 1-18
Committee Meeting: 1/19 - 1/20
Contact: Jan Zubkoff 415/329-8400
edsel!jlz@labrea.stanford.edu
∂25-Apr-88 1830 X3J13-mailer June Meeting addendum and varia
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Apr 88 18:30:01 PDT
Received: by labrea.Stanford.EDU; Mon, 25 Apr 88 18:30:08 PDT
Received: from bhopal.lucid.com by edsel id AA06559g; Mon, 25 Apr 88 18:24:58 PDT
Received: by bhopal id AA29363g; Mon, 25 Apr 88 18:26:52 PDT
Date: Mon, 25 Apr 88 18:26:52 PDT
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8804260126.AA29363@bhopal.lucid.com>
To: edsel!jlz@labrea.Stanford.EDU
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 25 Apr 88 14:05:18 PDT <8804252105.AA13882@sunvalleymall.lucid.com>
Subject: June Meeting addendum and varia
re: ***We are 2 weeks from subcommittee mailing time. Remember the
committee needs to have material in their hands 2 weeks before
the meeting or we can't legally vote.
I hope this is "4 weeks from subcommittee mailing time", not 2 weeks. Two
weeks before the meeting is May 31, and that is 5 weeks from now. Certainly
there is a lot of work that the cleanup committee will be doing "soon", but
will probably not finish in 2 weeks.
-- JonL --
∂25-Apr-88 1937 X3J13-mailer X3J13 Meeting
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Apr 88 19:36:46 PDT
Received: by labrea.Stanford.EDU; Mon, 25 Apr 88 19:36:57 PDT
Received: from bhopal.lucid.com by edsel id AA06593g; Mon, 25 Apr 88 18:28:41 PDT
Received: by bhopal id AA29416g; Mon, 25 Apr 88 18:30:39 PDT
Date: Mon, 25 Apr 88 18:30:39 PDT
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8804260130.AA29416@bhopal.lucid.com>
To: bouzane@scrc.symbolics.com
Cc: sun!clam!loop-groop@labrea.Stanford.EDU, mathis@a.ISI.EDU,
edsel!jlz@labrea.Stanford.EDU
Cc: Symbolics@scrc-pegasus, x3j13@sail.stanford.edu, bouzane@scrc-pegasus
In-Reply-To: Rosemary Bouzane's message of Thu, 21 Apr 88 11:38:19 est <8804211745.AA18145@edsel.lucid.com>
Subject: X3J13 Meeting
The Iteration subcommittee will need a room in which to meet; I suspect
that 2-5PM on Monday would be fine. We will be under 10 persons.
-- JonL --
∂26-Apr-88 0848 X3J13-mailer June Meeting addendum and varia
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Apr 88 08:48:48 PDT
Received: by labrea.Stanford.EDU; Tue, 26 Apr 88 08:48:52 PDT
Received: from sunvalleymall.lucid.com by edsel id AA09556g; Tue, 26 Apr 88 08:44:00 PDT
Received: by sunvalleymall id AA15756g; Tue, 26 Apr 88 08:45:36 PDT
Date: Tue, 26 Apr 88 08:45:36 PDT
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8804261545.AA15756@sunvalleymall.lucid.com>
To: edsel!jonl@labrea.Stanford.EDU
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jon L White's message of Mon, 25 Apr 88 18:26:52 PDT <8804260126.AA29363@bhopal.lucid.com>
Subject: June Meeting addendum and varia
I'm allowing 1 week slippage, 2 weeks mailing time and 2
weeks for folks to read it.
---jan---
∂27-Apr-88 0100 X3J13-mailer June Meeting addendum and varia
Received: from altura.Honeywell.COM by SAIL.Stanford.EDU with TCP; 27 Apr 88 00:59:30 PDT
Return-Path: <hadden@src.honeywell.com>
Received: by altura.Honeywell.COM (5.52/smail2.1/05-12-87)
id AA25025; Tue, 26 Apr 88 16:05:08 CDT
Posted-Date: Tue, 26 Apr 88 16:04:08 CDT
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA25662; Tue, 26 Apr 88 16:04:08 CDT
Date: Tue, 26 Apr 88 16:04:08 CDT
From: hadden@src.honeywell.com (George D. Hadden)
Message-Id: <8804262104.AA25662@pavo.src.honeywell.com>
To: edsel!jlz@labrea.Stanford.EDU
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 25 Apr 88 14:05:18 PDT <8804252105.AA13882@sunvalleymall.lucid.com>
Subject: June Meeting addendum and varia
hi jan, i'm planning to attend the hawaii meeting!
-geo
∂27-Apr-88 0104 X3J13-mailer June Meeting addendum and varia
Received: from altura.Honeywell.COM by SAIL.Stanford.EDU with TCP; 27 Apr 88 01:04:11 PDT
Return-Path: <hadden@src.honeywell.com>
Received: by altura.Honeywell.COM (5.52/smail2.1/05-12-87)
id AA24730; Tue, 26 Apr 88 13:53:07 CDT
Posted-Date: Tue, 26 Apr 88 13:52:08 CDT
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA23512; Tue, 26 Apr 88 13:52:08 CDT
Date: Tue, 26 Apr 88 13:52:08 CDT
From: hadden@src.honeywell.com (George D. Hadden)
Message-Id: <8804261852.AA23512@pavo.src.honeywell.com>
To: @CIM-VAX.HONEYWELL.COM:edsel!jlz@labrea.Stanford.EDU
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 25 Apr 88 14:05:18 PDT <8804252105.AA13882@sunvalleymall.lucid.com>
Subject: June Meeting addendum and varia
hi jan, i'm planning to attend the hawaii meeting!
-geo
∂28-Apr-88 1315 X3J13-mailer mail to bouzane for June X3 meeting
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Apr 88 13:15:31 PDT
Received: by labrea.Stanford.EDU; Thu, 28 Apr 88 13:15:40 PDT
Received: from sunvalleymall.lucid.com by edsel id AA02684g; Thu, 28 Apr 88 12:54:12 PDT
Received: by sunvalleymall id AA01699g; Thu, 28 Apr 88 12:55:58 PDT
Date: Thu, 28 Apr 88 12:55:58 PDT
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8804281955.AA01699@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: mail to bouzane for June X3 meeting
For those of you not able to reply to Rosemary's message try:
bouzane@symbolics.com
∂10-May-88 1438 X3J13-mailer X3J13 June Meeting
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 10 May 88 14:37:53 PDT
Received: from VIRGINIA-RAIL.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 256317; Tue 10-May-88 16:55:36 EDT
Date: Tue, 10 May 88 16:56 EDT
From: Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>
Subject: X3J13 June Meeting
To: x3j13@sail.stanford.edu
cc: x3j13@PEGASUS.SCRC.Symbolics.COM, bouzane@PEGASUS.SCRC.Symbolics.COM
Message-ID: <"19880510205606.1.bouzane@PEGASUS"@VIRGINIA-RAIL.SCRC.Symbolics.COM>
REMINDER - Deadline for room reservations at the Guest
Quarters Suite Hotel is MAY 12.
Below is registration form - it needs to be completed
ASAP.
The following is the schedule for Subcommittee Meetings:
6/13 - Monday: 2:00-5:00-Iteration Committee
@ Symbolics, Inc.
Eleven Cambridge Center
Cambridge
BONAIRE Conference Room
6/14 - Tuesday: 10:00-5:30-CLOS Committee
@ Symbolics, Inc.
Same address as above
BONAIRE Conference Room
1:00-5:30-Editorial Sub Committee
@ Symbolics, Inc.
Same address as above
ST. CROIX Conference Room
3:00-5:30-Definition Specs Group
@ Symbolics, Inc.
Same address as above
BERMUDA Conference Room
*******************************************************************
X3J13 JUNE MEETING REGISTRATION FORM
Please mail to:
Rosemary Bouzane
Symbolics, Inc.
Eleven Cambridge Center
Cambridge, MA 02142
(617) 621-7611
NAME:
INSTITUTION:
STREET ADDRESS:
CITY: STATE: PHONE:
NET ADDRESS:
SUBCOMMITTEE NAME:
NEED CONFERENCE ROOM FOR SUBCOMMITTEE MEETING:
DATE OF SUBCOMMITTEE MEETING:
NUMBER OF PEOPLE INVOLVED IN SUBCOMMITTEE MEETING:
WOULD LIKE A GROUP DINNER? YES NO
SUGGESTIONS:
TRAVEL ARRANGEMENTS:
PROPOSED DEPARTURE FROM/DATE/TIME:
AIRLINE PREFERENCE:
FREQUENT FLYER #:
PROPOSED RETURN TO/DATE/TIME:
∂10-May-88 2005 X3J13-mailer Re: June Meeting
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 10 May 88 20:05:10 PDT
Received: from en-c06.prime.com by RELAY.CS.NET id ab17213; 10 May 88 19:20 EDT
Received: from primerd.prime.com by EN-C06.Prime.COM; 10 May 88 18:36:00 EDT
Received: from zaphod.prime.com by primerd.prime.com (3.2/SMI-3.0DEV3/smail)
id AA01488; Tue, 10 May 88 18:37:12 EDT
Received: by zaphod.prime.com (3.2/SMI-3.2)
id AA08611; Tue, 10 May 88 18:37:30 EDT
Date: Tue, 10 May 88 18:37:30 EDT
From: Douglas Rand <doug@zaphod.prime.com>
Message-Id: <8805102237.AA08611@zaphod.prime.com>
To: x3j13@SAIL.STANFORD.EDU
Subject: Re: June Meeting
Cc: bouzane@SCRC-PEGASUS.ARPA
>> REMINDER - Deadline for room reservations at the Guest
>> Quarters Suite Hotel is MAY 12.
>> Below is registration form - it needs to be completed
>> ASAP.
Can the list of people already registered be posted?
Cheers,
Doug (doug@zaphod.prime.com)
∂16-May-88 1119 X3J13-mailer agenda items please
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 16 May 88 11:18:26 PDT
Received: by labrea.stanford.edu; Mon, 16 May 88 11:18:29 PDT
Received: from sunvalleymall.lucid.com by edsel id AA25724g; Mon, 16 May 88 11:07:51 PDT
Received: by sunvalleymall id AA28345g; Mon, 16 May 88 11:10:53 PDT
Date: Mon, 16 May 88 11:10:53 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8805161810.AA28345@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: agenda items please
If you have something that should be listed on the agenda please
let me know what it is and estimate how long you'll need.
Thanks.
---jan---
∂19-May-88 1621 X3J13-mailer mailing deadline approaches
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 19 May 88 16:21:42 PDT
Received: by labrea.stanford.edu; Thu, 19 May 88 16:21:53 PDT
Received: from sunvalleymall.lucid.com by edsel id AA12251g; Thu, 19 May 88 15:59:23 PDT
Received: by sunvalleymall id AA11292g; Thu, 19 May 88 16:02:38 PDT
Date: Thu, 19 May 88 16:02:38 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8805192302.AA11292@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: mailing deadline approaches
Documents need to be in committee hands by June 1 in order to vote on them at
the June 15-16 meeting. To meet this deadline documents should mailed by
Monday, 5/23. If you don't have your mailing labels yet please call Bob
Mathis ASAP.
---jan---
∂23-May-88 1640 X3J13-mailer June agenda draft
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 23 May 88 16:40:19 PDT
Received: by labrea.stanford.edu; Mon, 23 May 88 16:40:43 PDT
Received: from sunvalleymall.lucid.com by edsel id AA02178g; Mon, 23 May 88 16:25:52 PDT
Received: by sunvalleymall id AA02202g; Mon, 23 May 88 16:29:25 PDT
Date: Mon, 23 May 88 16:29:25 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8805232329.AA02202@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: June agenda draft
Please let me know if there are any changes or additions.
---jan---
X3J13 Committee Meeting Agenda DRAFT
June 15 - 16, 1988
1 Call to Order, June 15, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Editorial Subcommittee Report, Kathy Chapman (30 minutes)
6 Character Subcommittee Report, Thom Linden (20 minutes)
7 Iteration Subcommittee Report, Jonl White (15 minutes)
8 Definition Specs Proposal, Jonl White (30 minutes)
9 Lunch, 12:00pm - 1:00pm
10 CLOS discussion and vote (Doc: 88-002R, 88-003R), Danny Bobrow et.al.
11 Recess, 5:00pm
12 Call to Order, June 16, 9:00am
13 Clean-up, Larry Masinter
14 Lunch, 12:00pm - 1:00pm
15 Other committee reports
16 Adjournment, 5:00pm
∂30-May-88 1838 X3J13-mailer mailing list and next meeting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 30 May 88 18:38:41 PDT
Date: 30 May 1988 18:33-PDT
Sender: MATHIS@A.ISI.EDU
Subject: mailing list and next meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]30-May-88 18:33:39.MATHIS>
Dear X3J13 members and observers:
This letter is a last minute reminder about the upcoming meeting
in Boston and a revalidation of our mailing lists.
You should receive two copies of this letter -- one electronic
and one physical. Our electronic mailing list is at x3j13@
sail.stanford.edu. If you did not receive a copy of this letter
through that means, please notify x3j13-request@sail.stanford.
edu. That is the primary means of communication within this
committee. If you do are not able to access electronic mail,
please notify me at the address on the letterhead. If you did not
receive a physical copy of this letter, please notify me at
Mathis@a.isi.edu.
If you wish to remain on the physical mail distribution list and/
or maintain your membership status on X3J13 you must reply to
this letter (either electronically, by physical mail, or by
attending the upcoming meeting in Boston). The cost of physical
mailings has become substantial. The committee is moving into a
stage where more formal voting will take place and I must be sure
about the membership and fee payment status of each participant.
At the meeting in Boston we will be voting on the final version
of the CLOS documents. These are being physically mailed to you
separately. We will also be considering language issues which are
being distributed electronically (hard copies will be available
in Boston). We will also be considering reports from the
iteration, errors and conditions, character set, editorial, and
other subcommittees. Hard copies of the documents will be
available there. With the exception of the CLOS vote we will be
operating in the kind of "committee of the whole" status we have
been using.
If you have not already made your arrangements for the Boston
meeting (which will be June 13-17), please contact Rosemary
Bouzane, Symbolics, Inc., Eleven Cambridge Center, Cambridge, MA
02142, (617) 621-7611. I will be out of town the week proceeding
the meeting. An alternate contact is Jan Zubkoff, Lucid, 707
Laurel St., Menlo Park, California 94025, (415)329-8400.
Thank you,
Robert F. Mathis
Chairman, X3J13
∂02-Jun-88 1614 X3J13-mailer 88-007
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Jun 88 16:14:52 PDT
Received: by labrea.stanford.edu; Thu, 2 Jun 88 16:15:16 PDT
Received: from bhopal.lucid.com by edsel id AA02715g; Thu, 2 Jun 88 16:13:01 PDT
Received: by bhopal id AA27781g; Thu, 2 Jun 88 16:11:01 PDT
Date: Thu, 2 Jun 88 16:11:01 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806022311.AA27781@bhopal.lucid.com>
To: x3j13@sail.stanford.edu
Subject: 88-007
Document 88-007 on The LOOP Facility (James Bond Edition?) is intended to
be a draft proposal for specification of the MIT-style LOOP. I cobbled its
text from Lucid documentation, which is being made available to X3J13 free
of any encumbrances. Unfortunately, some mechanically-generated copyright
notice still crept into one page; it should simply be disregarded.
A number of good comments and suggestions for changes have already come in
on this proposal. I will continue to update the text accordingly [unless
and until the editorial committee wants to take it over].
-- JonL --
∂07-Jun-88 1559 X3J13-mailer Issue: FUNCTION-TYPE (version 11)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jun 88 15:59:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 JUN 88 15:59:26 PDT
Date: 7 Jun 88 15:59 PDT
From: Masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 11)
line-fold: NO
Message-ID: <880607-155926-1276@Xerox>
Due to a combination of circumstances, I've been unable to work on cleanup activities. The
committee has proceeded admirably, but I've been behind in summarizing. Since I've been behind,
any decisions made at X3J13 will be preliminary. I will bring some hardcopy of these issues to
the meeting.
However, the issue FUNCTION-TYPE was discussed at length at the last X3J13. This version is our
attempt to recast it according to the wishes expressed at the last meeting.
!
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
19-May-88, Version 10 by Masinter, (modify as per X3J13)
24-May-88, Version 11 by van Roggen
(don't coerce lists, relax SYMBOL-FUNCTION reqs)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
Proposal FUNCTION-TYPE:X3J13-MARCH-88
This proposal is basically the STRICT-REDEFINITION proposal of version 9
of this issue, correcting a few typos, changing section 2E as
agreed upon at X3J13 March 1988, allowing symbols but not lists to
be FUNCALLed or APPLYed, and relaxing some SYMBOL-FUNCTION/FBOUNDP
requirements.
1. Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint. In particular, a list may not be used
to implement any FUNCTION subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
2. Define that a ``function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.
2a. This type no longer includes objects of type SYMBOL or lists
whose CAR is LAMBDA.
2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible
change.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Clarify FUNCALL and APPLY and all Common Lisp functions that
take functional arguments such that they accept objects that
are coerceable to a FUNCTION as the functional argument. It
is an error if the functional argument is not coerceable to a
FUNCTION.
3. Clarify that the result of a FUNCTION special form must be a function.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that FBOUNDP must return true for a symbol naming a macro or
a special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. SETF of SYMBOL-FUNCTION requires a FUNCTION as the new value.
It is an error to set the SYMBOL-FUNCTION of a symbol to a
symbol or a list or the value returned by SYMBOL-FUNCTION on
the name of a macro or a special form.
5c. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
6. COERCE is extended to allow objects to be coerced to type FUNCTION.
6a. (COERCE symbol 'FUNCTION) extracts the SYMBOL-FUNCTION of the
given symbol, signalling an error if the symbol is not FBOUNDP or
if the symbol names a macro or a special-form.
6b. Implementations are free to extend the set of objects which
are coerceable to a FUNCTION, particularly lambda-expressions
for compatibility. However, such extensions will not be portable.
7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the expansion interface hook by
MACROEXPAND-1.
Rationale:
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
This proposal is a compromise between a CONSERVATIVE proposal (which left
FUNCTION alone and introduced a new type), and a STRICT-REDEFINITION proposal,
which incompatibly changed not only the FUNCTION type and SYMBOL-FUNCTION,
but also the behavior of FUNCALL, APPLY and functions with functional
arguments.
For compatibility reasons symbols are still acceptable to FUNCALL et al.,
but for aesthetic reasons lambda-expressions (lists whose CAR is LAMBDA
and whose CADR is a list) are no longer acceptable.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is true for values
returned by FUNCTION, symbols that are FBOUNDP, and lambda expressions.
In some implementations, (TYPEP x 'FUNCTION) is true only for values
returned by FUNCTION.
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations have exactly the
semantics described in this proposal.
Cost to Implementors:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations.
Compiled functions are true functions in almost all current
implementations, but in many implementations, interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, this representation would have to be different
(implemented either as structures or as some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).
Cost to Users:
The changes to FUNCTIONP and the FUNCTION type declaration are relatively easy
to deal with.
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell, or expected lists back, will
have to change. Such code was already not portable, however, since some
implementations signal an error when this is done.
The original STRICT-REDEFINITION proposal required users to deal with
the use of symbols and lambda-expressions as functional arguments. However
this proposal is compatible with current CLtL definition in the use of
symbols, which would be the hardest change to make. There are probably
relatively few uses of lambda-expressions as ``functions'', which can
be dealt with by (EVAL `(FUNCTION ,lambda-expresssion)).
Benefits:
The term ``function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.
The type hierarchy would be simplified.
This proposal brings Common Lisp slightly closer to Scheme and the
work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with the FUNCTION type.
Aesthetics:
This proposal improves the aesthetics of the language.
Lambda-expressions do not obey the normal, apparent scoping rules because
free variables cannot refer to lexical bindings. This is because
coercing a list to a function would mean (EVAL `(FUNCTION ,list)).
The following code does -not- count the number of nodes in a graph:
(LET ((COUNTER 0))
(TRAVERSE-THING '(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
since it is not the same as
(LET ((COUNTER 0))
(TRAVERSE-THING #'(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
which does pass around a closure incrementing the LET variable.
(These examples assume COUNTER wasn't PROCLAIMed SPECIAL.)
Making the coercion of lambda-expressions to functions explicit with
the use of EVAL will encourage less confusing code and also highlight
that use of EVAL.
Discussion:
This issue has been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Many different alternatives have been discussed both in the cleanup committee
and X3J13. Two proposals were circulated at the March 1988 meeting of X3J13;
this version is the result of discussions at that meeting. It is a compromise
between the conflicting goals of backward compatibility, flexibility in the
language, and simple semantics.
This proposal does not address the issue of when coercion to functions occur.
For example, it is allowed to write
(MAPCAR 'FROB my-list)
It is not specified when the coercion of FROB to its SYMBOL-FUNCTION
occurs. For example,
(DEFUN FROB (X)
(WHEN (> X 0) (SETF (SYMBOL-FUNCTION 'FROB) #'(LAMBDA (X) NIL)))
T)
(MAPCAR 'FROB '(-1 -1 1 1))
may return different results if MAPCAR coerces its functional argument
once rather than for each element. This may require a separate
cleanup issue.
∂08-Jun-88 1211 X3J13-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 12:11:39 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 12:07:56 PDT
Date: 8 Jun 88 12:07 PDT
From: Masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Subject: Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
Line-fold: NO
Message-ID: <880608-120756-2864@Xerox>
!
Issue: ADJUST-ARRAY-FILL-POINTER
References: ADJUST-ARRAY (p297)
Category: CLARIFICATION
Edit history: 15-Mar-88, Version 1 by Pitman
Problem Description:
CLtL does not specify clearly the effect of ADJUST-ARRAY on the fill
pointer.
Proposal (ADJUST-ARRAY-FILL-POINTER:MINIMAL):
Clarify that the :FILL-POINTER keyword argument to ADJUST-ARRAY is treated
as follows...
If :FILL-POINTER argument is not given, then the fill-pointer of the array
to be adjusted (if any) is left alone. It is an error to adjust an array
to a size smaller than its fill pointer without specifying the :FILL-POINTER
option so that its fill-pointer is properly adjusted in the process.
If supplied, the :FILL-POINTER argument must be either an integer between 0
and the new size of the array, the symbol T (indicating that the new size
of the array should be used), or the symbol NIL (indicating that the fill
pointer should left as it is -- as if the :FILL-POINTER option had not been
specified).
An error is signalled if a non-NIL value for :FILL-POINTER is supplied and
the array to be adjusted does not already have a fill pointer.
Test Case:
(SETQ A1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
(SETQ A2 (ADJUST-ARRAY A1 4))
(FILL-POINTER A1) => 3
(FILL-POINTER A2) => 3
(SETQ B1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
(SETQ B2 (ADJUST-ARRAY B1 2 :FILL-POINTER 1))
(FILL-POINTER B1) => 1
(FILL-POINTER B2) => 1
(SETQ C1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
(SETQ C2 (ADJUST-ARRAY C1 2 :FILL-POINTER T))
(FILL-POINTER C1) => 2
(FILL-POINTER C2) => 2
(SETQ D1 (MAKE-ARRAY 5 :ADJUSTABLE T))
(SETQ D2 (ADJUST-ARRAY D1 2 :FILL-POINTER 2)) signals an error.
(SETQ E1 (MAKE-ARRAY 5 :FILL-POINTER T :ADJUSTABLE T))
(SETQ E2 (ADJUST-ARRAY E1 4)) is an error.
Rationale:
This behavior must be more clearly defined if portable programs are going
to be able to depend on it.
Current Practice:
Symbolics Lisp implements the proposal. In case "E", it does not signal an
error. It simply leaves the illegal fill-pointer in place so that the
programmer can correct it using (SETF (FILL-POINTER E2) ...)
Cost to Implementors:
Probably most implementations do not deviate significantly from the proposed
behavior. The cost to implementors is probably very slight.
Cost to Users:
None. This clarifies a fuzzy area in the manual which users cannot currently
depend upon.
Cost of Non-Adoption:
The interaction between ADJUST-ARRAY and fill-pointers would continue to be
hazy, and portable programs would not be able to rely upon that behavior
being consistent across implementations.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
There is little if any aesthetic impact of this change.
Discussion:
Pitman volunteered to write this issue up for the Cleanup committee. He's
not very passionate about the details one way or another, but figures it's
a good idea that they be clarified.
The cleanup committee didn't object.
∂08-Jun-88 1237 X3J13-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 12:36:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 12:25:42 PDT
Date: 8 Jun 88 12:25 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
Subject: Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 1)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <880608-122542-2920@Xerox>
There's been no discussion (and no objections) to this issue.
!
Issue: DATA-TYPES-HIERARCHY-UNDERSPECIFIED
References: CLtL 33-35 (data types)
CLtL 312 (DEFSTRUCT :INCLUDE option)
Category: CHANGE
Edit history: 24-Mar-88, version 1 by Steele
Problem description:
The types HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, and
RANDOM-STATE currently are not required to be disjoint from CONS, SYMBOL,
ARRAY, NUMBER, or CHARACTER. The same is true of DEFSTRUCT types. With
the arrival of CLOS, lack of disjointness will be inconvenient because one
cannot reliably use generic function dispatch on these types.
Proposal (DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT):
Remove the third and antepenultimate bulleted items from section 2.15 is
CLtL and replace with the following:
* The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, HASH-TABLE, READTABLE,
PACKAGE, PATHNAME, STREAM, RANDOM-STATE, and any single other type created
by DEFSTRUCT [or DEFCLASS] are pairwise disjoint.
Also, in the discussion of the DEFSTRUCT :INCLUDE option, explicitly forbid
the type given to the :INCLUDE option to be CONS, SYMBOL, ARRAY, NUMBER,
CHARACTER, HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, or
RANDOM-STATE.
Rationale:
It would be useful to extend sequence functions to operate on streams
or hash tables, for example, through the CLOS generic function mechanism.
This is not possible under the current specification.
Current practice:
Some implementations in effect use DEFSTRUCT to define data structures
such as hash tables and random-states.
Cost to Implementors:
Small or nonexistent. The main reason this disjointness was not specified
in CLtL was the possibility that structures might not be easily
distinguishable: a stupid concern over a slight efficiency. This
implementation freedom apparently has not been exploited in practice.
Cost to Users:
None.
Cost of non-adoption:
CLOS will be less useful.
Benefits:
CLOS will be more useful.
Esthetics:
This makes the type system simpler and easier to understand.
Discussion:
This suggestion originated in the CLOS committee.
∂08-Jun-88 1244 X3J13-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 12:44:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 12:39:58 PDT
Date: 8 Jun 88 12:39 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@Sail.stanford.edu
Subject: Issue: DECLARATION-SCOPE (Version 2)
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <880608-123958-2954@Xerox>
There was significant discussion of this issue in the cleanup committee after
Version 2 was distributed, but no revision of the proposal has been produced.
This DRAFT is for your information and discussion at the June X3J13 meeting, but
it is not in final form.
!
Status: DRAFT
Issue: DECLARATION-SCOPE
References: Section 9.1 (pp. 153-157).
Cleanup issue FLET-DECLARATIONS.
Category: CHANGE
Edit history: V1: Hornig@Symbolics.COM -- 5 January 1988
Version 2, Moon, 2-Feb-1988 (edits based on discussion)
Problem description:
The description of the scope of declarations made with DECLARE is both
unclear (although unambiguous) and arguably a mistake. The issue is
whether the scope of some or all of the declarations includes code
appearing in the non-body part of the special form containing the
declaration.
Proposal DECLARATION-SCOPING:LIKE-VARIABLE:
For the purposes of this proposal, we divide all declarations introduced
with DECLARE into two classes. When a declaration of a variable appears
before the body of a special form or lambda-expression that binds that
variable, the declaration is called `bound'. All other declarations
are called `free'. This division replaces the division into pervasive,
nonpervasive, and SPECIAL declarations appearing in CLtL.
The scope of a `bound' declaration is exactly the scope of the
associated lexical variable or function. If the declaration is
associated with a special variable, the scope is the scope the variable
would have had if it had not been special.
`Free' declarations are scoped as if they appeared in a new LOCALLY form
which surrounded the entire special form at the beginning of whose body
the declaration appears. This is the same as what CLtL p.155 defines to
be the scope of `pervasive' declarations.
The following is a complete listing of the types of declarations and
their class (`bound' or `free'):
SPECIAL declarations may be either `bound', affecting both a binding and
references, or `free', affecting only references, depending on whether
the declaration is attached to a variable binding, as described above.
TYPE declarations may only be `bound' (see next section).
FTYPE and FUNCTION declarations may only be `free' (see next section).
INLINE declarations may only be `free' (see next section).
NOTINLINE declarations may only be `free' (see next section).
IGNORE declarations may only be `bound'.
OPTIMIZE declarations may only be `free'.
The `free' or `bound' scoping of implementation-dependent declaration
specifiers is implementation-dependent.
Interactions with other proposals:
There has been some discussion in X3J13 of permitting `free' TYPE
declarations. This is a semantic issue, not a scoping issue, and should
be treated independently.
If Common Lisp is extended to permit declarations in FLET and LABELS
forms, by acceptance of cleanup proposal FLET-DECLARATIONS:ALLOW,
then declarations of functions (FTYPE, FUNCTION, INLINE, and
NOTINLINE) which appear before the body of a FLET or LABELS form which
defines that function are `bound'. Such declarations in other contexts
remain `free'.
Common Lisp is ambiguous about whether a variable may be bound several
times by a single form. It has been proposed that multiple bindings be
permitted for LET*, DO*, PROG* forms and for &AUX variables in lambda
expressions. If multiple bindings are permitted, `bound' declarations
are treated as if there were a separate `bound' declaration for each of
the bindings.
Examples:
;;; Some examples of `free' and `bound' declarations.
(let ((a 1))
(declare (optimize speed)) ;this is a `free' declaration
(let ((b 2))
(declare (type integer b)) ;this is a `bound' declaration
(declare (special a)) ;this is a `free' declaration
()))
;;; This example applies if you believe that FLET may have declarations.
(flet ((foo (x) (1+ x)))
(declare (notinline foo)) ;this is a `bound' declaration
(declare (notinline 1+)) ;this is a `free' declaration
())
;;; The following code is from Pavel.
;;; It produces 7 in existing implementations.
;;; If the proposal is adopted, it will produce 8.
(let ((foo 6)) ;a special binding of FOO
(declare (special foo)) ;`bound' declaration
(let ((foo 7)) ;a lexical binding of FOO
(let ((foo (1+ foo))) ;is the second FOO special or not?
(declare (special foo)) ;`bound' declaration
foo)))
;;; Treatment of LET* under the proposal if multiple bindings of the same name
are allowed.
;;; This form produces the value 9.
(let ((foo 6)) ;a special binding of FOO
(declare (special foo)) ;`bound' declaration
(let ((foo 7)) ;a lexical binding of FOO
(let* ((foo (1+ foo)) ;special binding, lexical reference
(foo (1+ foo))) ;special binding, special reference
(declare (special foo)) ;`bound' declaration, applies to both bindings
foo)) ;special reference
Rationale:
`Bound' declarations are made to control a particular binding of a
variable and should be scoped the same way as that binding. This is as
true of `bound' declarations which were pervasive under the old rules
as it is of those that were not.
Current practice:
The `bound'/`free' division based on context replaces CLtL's static
pervasive/nonpervasive/SPECIAL division. Most implementations implement
the rules in CLtL. Symbolics currently implements rules based on
Zetalisp which are different from both this proposal and Common Lisp.
Symbolics plans to change to Common Lisp rules in the future.
Cost to Implementors:
The cost of implementing this change should be moderate. The change
will be localized to a handful of places in the compiler and interpreter
which apply declarations to variables. The other cost would be in
providing tools for users to find programs whose meaning will change.
Cost to Users:
The proposal changes only the treatment of `bound' declarations. This
change will break very few existing production programs.
It is possible to mechanically examine a program to determine whether
its behavior would change under the new rules. This permits an
implementation to provide a transition tool to ease conversion to the
new definition.
Cost of non-adoption:
The ability of a `bound' declaration to affect code outside the scope
of the variable which it appears to declare has led to endless confusion
and discussion at Symbolics, on the Common-Lisp mailing list, and
elsewhere. It will continue to do so unless it is smoothed over somehow.
Benefits:
The costs of non-adoption will be avoided.
Aesthetics:
The distinction between `bound' and `free' declarations introduced by
this proposal is a natural one.
Discussion:
A proposal to forbid `free' declarations except in LOCALLY forms and a
proposal to have `free' declarations affect only the body were discarded
as being too incompatible.
The mapping from the existing pervasive/nonpervasive/SPECIAL division of
declarations and the one proposed here is complex. In general,
nonpervasive declarations are `bound' and pervasive declarations are
`free'. SPECIAL declarations are either `bound' or `free' based on
their context, and are no longer treated as a special case.
Some historical support for having `free' and `bound' declarations:
Date: Tue, 20 Dec 83 15:50 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Declarations
To: Common-Lisp@SU-AI.ARPA
...
There are two disjoint classes of declaration: those that are attached
to a particular variable binding, and those that are not. Note that I
am not discussing proclamations here; they have their own scoping rules
which are different from the rules for declarations.
The scoping rule for the first kind of declaration is that it applies to
precisely the text that is in the lexical scope of the variable binding
with which it is associated. Such declarations are shadowed by a
variable binding for the same name inside their scope. Since the
lexical scoping rules are very well and precisely defined, we already
understand everything about this kind of declaration.
The scoping rule for the second kind of declaration is that it is
pervasive. The declaration is attached to a lambda-expression or to a
form (one of the special forms listed on page 125). The declaration
applies to all text inside that expression or form; there are no special
cases such as init-forms of LET or DO. Such declarations are shadowed
by a conflicting declaration inside their scope.
Possible names for the two kinds of declaration are "lexical" and
"pervasive" or "variable" and "non-variable."
...
∂08-Jun-88 1509 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 15:09:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 15:09:25 PDT
Date: 8 Jun 88 15:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
TO: x3j13@Sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <880608-150925-3305@Xerox>
!
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References: CLtL p.308 & 86-003 p.4
Category: CLARIFICATION
Edit history: Version 1 by Skona Brittain 05/13/88
Problem Description:
The case of two slots of a structure having the same name is not
discussed in CLtL.
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):
It is an error for two slots in a structure type to have the same name.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.
Test Cases:
(defstruct struc slot slot) would be an error. So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).
Rationale:
Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error. Checking for it
would be costly so signaling this error is not required.
Current Practice:
In KCL, if 2 slots have the same name, no warning message is
given but mysterious behavior ensues. (Their default values are
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the
second one's value can be changed by setf...)
Cost to Implementors:
None.
Cost to Users:
None.
Cost of Non-Adoption:
Possible confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
∂08-Jun-88 1524 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 15:19:13 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 15:12:04 PDT
Date: 8 Jun 88 15:11 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER (Version 1)
TO: x3j13@Sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
LINE-FOLD: NO
Message-ID: <880608-151204-3312@Xerox>
!
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
References: CLtL p.307 & 86-003 p.4
Category: CHANGE
Edit history: Revision 1 by Skona Brittain 05/13/88
Problem Description:
Structures defined by defstruct currently are required to have at least
one slot. This seems to have been a mistake in the design of the language.
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER:ALLOW-ZERO):
Allow a call to defstruct to have zero slot-descriptions.
i.e. change the + to a * in the syntax of calls to defstruct
given at the bottom of page 307 of CLtL.
Test Case:
(defstruct s), which is not allowed according to CLtL, would be allowed.
Rationale:
The current restriction is in marked contrast to the generality allowed
elsewhere in the language. And removing it slightly increases the
usefulness of defstruct - by allowing the zero slot case when it may be
deemed useful and by not requiring a check for it when it doesn't matter.
Current Practice:
KCL allows zero slots.
Cost to Implementors:
None for implementations that currently allow zero slots.
Very slight for others.
Cost to Users:
None.
Benefits:
Slightly increases the usefulness of defstruct and is aesthetic.
Aesthetics:
In general, it is more aesthetic to allow for generality rather than to
specifically prohibit a particular case. And the generality in this case
is consistent with that of many other features of the language, such as
that arrays can be empty, functions like + and list can take zero arguments,
etc.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
∂08-Jun-88 1531 X3J13-mailer Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 15:31:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 15:24:52 PDT
Date: 8 Jun 88 15:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
TO: x3j13@Sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
LINE-FOLD: NO
Message-ID: <880608-152452-3341@Xerox>
!
Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
References: CLtL p.308-10 & 86-003 p.4
Category: CLARIFICATION
Edit history: Revision 1 by Skona Brittain 05/13/88
Problem Description:
There is some confusion over whether default initialization
forms for defstruct slots get evaluated, when they are not needed
because a keyword argument was supplied to the constructor function.
As a consequence of this confusion, there is confusion over whether
there can be a type-mismatch error between the specified type of the slot
and the type of the default value.
On page 308, it says "The default-init is a form that is evaluated
each time a structure is to be constructed; the value is used as the
initial value of the slot. If no default-init is specified, then the
initial contents of the slot are undefined and implementation-dependent."
On the next page, however, it says that the default-init is evaluated if
the keyword argument is not supplied and the converse, although not stated,
is intended and informally implied.
Proposal (DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED):
Clarify that the converse is true. i.e that the default-init is not evaluated
if the keyword argument is supplied.
In the quote from page 308, delete the second sentence and replace
"a structure is to be constructed; the value is" by "its value is to be".
To section 19.3, add a clarification,
such as the following from Guy's issues file:
"The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Test Case:
In the following sequence, only the last call is an error.
(defstruct person (name 007 :type string))
(make-person :name "James")
(make-person)
Rationale:
It is inefficient, and inconsistent with the rest of the language, for the
default initialization form to be evaluated when it is not needed.
Consequently, when it's not needed, such type-mismatch errors should not be
detectable in general.
Any existing confusion should be clarified by this proposal.
Current Practice:
KCL does not evaluate the default initialization form unless it is needed;
even when it is needed, the type checking is not done at all.
Cost to Implementors:
If there are any implementations that currently behave differently from
the proposed way, then they need some slight modification.
Cost to Users:
None.
Benefits:
Clarity and portability. In particular, clarifying that the unaesthetic
situation mentioned in the next section is allowed should be reassuring.
Aesthetics:
It appears slightly unaesthetic to have a default value that violates a
type specification.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
!
Additional notes:
Several members of the cleanup committee endorsed this proposal.
JonL added:
You can add to the "Current Practice:" section:
LUCID does not evaluate the default initialization form unless it is
needed; even when it is needed, the type checking is not done at all.
However, at structure definition time, if an initial value form is
constanp and doesn't satisfy the :type specification, a warning message
is printed.
Oddly enough, Lucid's interpreter ensures that SETF's of slots obey the
:type specifier, even though init-forms aren't checked. Furthermore, in
safety levels 2 or higher, the compiled code will do minimal "memory-
integrity" type checking for SETF's (which is what I suspect the various
special-purpose microcoded machines do); however except for low-level numeric
types, this is rarely equivalent to what a full type check would do.
I have long suggested that there should be at least one mode of operation
such that all :type information is checked when setting values into structure
slots (setf as well as initialization). Some have suggested that this mode
could be "when running interpretively, or when when compiled with the highest
degree of SAFETY and lower degrees of SPEED." However, since the wording of
CLtL p310 suggests that the :type slot options is merely a DECLARE, and since
some vendors effectively ignore any and all declarations [except for SPECIAL],
then this suggestion hasn't reached proposal stage yet.
∂08-Jun-88 1806 X3J13-mailer Issue: EVAL-OTHER (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 18:06:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 18:03:17 PDT
Date: 8 Jun 88 18:03 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: EVAL-OTHER (Version 2)
To: X3J13@SAIL.Stanford.EDU
reply-to: CL-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Line-fold: NO
Message-ID: <880608-180317-3640@Xerox>
I have some notes about some possible additional opposition to this proposal. I hope
we can discuss it at the June X3J13 meeting.
!
Issue: EVAL-OTHER
References: 5.1.1 Self-Evaluating Forms (p55)
Category: ADDITION/CLARIFICATION
Edit history: 07-Mar-88, Version 1 by Pitman
8-Jun-88, Version 2 by Masinter (correct typo, add to discussion)
Problem Description:
CLtL does not specify what the evaluation behavior of some data types.
Proposal (EVAL-OTHER:SELF-EVALUATE):
Standard data types (those mentioned by CLtL) other than those for which
a more explicit evaluation rule exists would be defined to self-evaluate.
Such data types include, for example, structures, arrays, vectors, and
pathnames.
Structure types defined by users using DEFSTRUCT should also self-evaluate
unless an explicit implementation type for the structure is given in the
DEFSTRUCT, in which case the rule for evaluation of that type should be
used. (This is important in the case of type LIST.)
Test Case:
(LET ((TEMP (MAKE-PATHNAME))) (EQ TEMP (EVAL TEMP))) => T
(LET ((TEMP (MAKE-ARRAY NIL))) (EQ TEMP (EVAL TEMP))) => T
Rationale:
There are numerous possible positions that could be taken, from
requiring that an error be signalled for all of these cases to
requiring that these all have some useful behavior.
By making implementations agree, code portability is enhanced.
By biasing the decision away from the "signal
an error" end of the choice spectrum, the least interruption is
caused to implementations which already have working code.
There is still some chance that implementations will have some other
behavior than either signalling an error or self-evaluating, but there
are probably few if any.
Current Practice:
In many implementations, the other data types besides those mentioned in
CLtL will self-evaluate.
Cost to Implementors:
The cost is probably small. This is probably an "upward compatible"
change for most or all implementations -- a few lines of change in the
interpreter and/or compiler. Some code walkers may be affected as well.
Cost to Users:
None, if they are not exploiting implementation-dependent features of
some implementation that is being forced to make an incompatible change.
There should be no performance impact since the evaluator's test for these
new data types can simply be made to follow other tests already in place,
so existing code will not be slowed.
Cost of Non-Adoption:
Implementations will continue to differ in this relatively
user-visible way.
Benefits:
Portability will be enhanced because implementations will tend to agree
in places where they have traditionally not always agreed.
Aesthetics:
Some fans of 3LISP may find this invasive to their sense of distinction
between objects and the notation used to describe objects. In general,
however, this is a fairly picky detail that is not likely to trouble the
average programmer.
Discussion:
This idea for this proposal was suggested by the Japanese community.
Pitman drafted the formal proposal and supports EVAL-OTHER:SELF-EVALUATE.
Fahlman: "... I do remember the original design discussions. It was
proposed that everything but lists and symbols evaluate to themselves,
but at the time (this was quite early in the process) some people felt
that this might close out interesting parts of the design space that
might turn out to be useful for something. This hasn't happened, and
I think it would be reasonable to close this door now. Some users do
find it confusing that you have to quote vectors but not strings."
There has been some additional discussion of this proposal (for example,
an explaination of why a similar proposal in Scheme might be a bad design.)
∂08-Jun-88 1752 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 17:51:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 17:47:35 PDT
Date: 8 Jun 88 17:47 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE (Version 2)
TO: x3j13@Sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
LINE-FOLD: NO
Message-ID: <880608-174735-3615@Xerox>
This issue is a DRAFT; I hope that discussion at X3J13 can help the cleanup committee focus on the most popular options.
!
Status: DRAFT - for discussion at June X3J13
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
8-Jun-88, Version 2 by Masinter (add Benson's proposal)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:RADICAL):
Remove EQUAL and EQUALP from the language. (Naturally, they could be retained
as implementation-dependent extensions.)
Rationale:
The name "EQUAL" suggests something very generic. It conjures in the mind
of the naive user the notion that there is a single, uniquely selected
predicate which is always good for equality testing. In fact, there is a
large space of useful equality predicates, each good for different
applications, and the choice of the current definition of EQUAL is
exceedingly arbitrary. Although the function chosen is sometimes quite
useful and some work is occassionally saved by having it be defaultly
available, confusion frequently results from its presence. Users for whom
the operator is not appropriate are inclined to describe it as broken,
rather than to recognize that it does a useful thing but that the
application they have does not call for that useful thing. The thing which
would be useful to them would not be useful in other situations. There is
simply no unique solution. The absence of the operator EQUAL would cause
people to think explicitly about what kind of equivalence is appropriate
to their application, and to write something better suited to that
application.
As an aside, this same notion of uniqueness carries over to COPY. People
have been observed to assert that a generic COPY function should be
present for copying arbitrary objects. A single COPY function is not
provided because there are many kinds of copying and no single function is
entitled to the generic name COPY. This argument does not sit well with
programmers who assert that if this is true, there should be no unique
EQUAL operator. We could solve that problem two ways -- one by creating a
COPY operator; another by eliminating the embarrassment of EQUAL and
friends.
Proposal (EQUAL-STRUCTURE:STATUS-QUO):
Leave things as is.
Rationale:
The intent of a structure is different than the intent of an array. A
list is an anonymous entity which makes sense only in terms of its
length and contents, and is not rightly compared just by object identity
(EQ); a structure, on the other hand, has an identity of its own and is
appropriately compared with EQ.
Proposal (EQUAL-STRUCTURE:DESCEND):
Change EQUAL and EQUALP to descend structure slots.
Rationale:
A structure is a container and, like many other containers in Lisp,
should be compared by recursing into the contents of that container.
Proposal (EQUAL-STRUCTURE:ADD-KEYWORDS):
Add :TEST and :TEST-NOT keywords to EQUAL saying what comparison operator
to use at the leaves.
[This will need more details if anyone decides they want to push this line
of reasoning. I don't claim to have done an adqeuate job of laying the
issue out, though I could imagine someone doing so. -kmp]
Rationale:
There's ample precedent for resolving sticky situations like this in
Common Lisp by just adding a keyword option. :-)
Proposal (EQUAL-STRUCTURE:ADD-OPERATOR)
Introduce new operator(s) like EQUAL (and/or EQUALP) which descends
structures.
Rationale:
If people don't want to make EQUAL more complicated, but still like
the idea of a keyword-driven EQUAL, this is the only way to get it.
Proposal (EQUAL-STRUCTURE:CHANGE-EQUALP):
Change EQUALP so that it descends structures, is case sensitive, and
never considers numbers of different types to be equal.
Rationale:
Several users have independently inquired why there is no predicate
with this definition in Common Lisp. Also, use of EQUALP is not
widespread. Rather than invent a new name for a predicate, it
would be preferable to take an existing name which is not being
heavily used and give it a more useful definition.
It would also be useful to have EQUALP type hashtables, given this
new definition for EQUALP.
EQUALP did not exist in Lisp dialects preceding Common Lisp. There
are few programs that make use of EQUALP and only those depending
on case insensitivity or numeric coercion (or lack of structure
descending) would be affected.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Current Practice:
There is no particular ambiguity in CLtL right now, so presumably
everyone agrees. The only question is whether what CLtL says is
sufficiently useful in practice.
Cost to Implementors:
The cost to implementors of most of these options is generally small.
The exception is that the ADD-KEYWORDS option may require hairy compiler
optimizations in order to get back the efficiency that a keyword would lose.
Cost to Users:
Writing an EQUAL or EQUALP function which is like the one that Common Lisp
now has would not be that hard to do as a compatibility measure in case
EQUAL or EQUALP were changed or removed. So the cost to users is technically
small.
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
Aesthetic considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
The ADD-KEYWORDS option will be the most controversial because some people
don't like keywords and some compiler writers will not like having to
optimize the keywords.
Discussion:
Pitman strongly supports EQUAL-STRUCTURE:RADICAL as the correct choice from
a purely language design standpoint, but acknowledges that it may not
ultimately be deemed practical for pragmatic reasons.
Eric Benson supports EQUAL-STRUCTURE:CHANGE-EQUALP. He has never
used EQUALP in a "serious" program, but in every "casual" use he has
wished that it was case sensitive.
∂08-Jun-88 1918 X3J13-mailer Issue: DEFPACKAGE (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 19:17:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 19:17:03 PDT
Date: 8 Jun 88 19:16 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFPACKAGE (version 2)
To: X3J13@Sail.Stanford.EDU
cc: Masinter.pa@Xerox.COM
reply-to: CL-Cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-191703-3760@Xerox>
This issue is still a DRAFT. The ongoing discussion, however, centers
around the details of the operations of some of the keyword arguments
(e.g., should :IMPORT-FROM take strings instead of/as well as symbols.)
!
Status: DRAFT - for discussion at June 1988 X3J13 meeting
Issue: DEFPACKAGE
References: CLtL section 11.7.
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 23-Mar-88, Moon, changes based on discussion
Problem description:
The package functions included in CLtL encourage a programming style
that tends to evoke the worst aspects of the package system. The
problem is that if the definition of a package is scattered through
a program, as a number of individual forms, it is very easy to read
a symbol before the package setup needed to read that symbol correctly
has been accomplished. Three examples: an inherited symbol that should
have been shadowed might be accessed; a single-colon prefix might be
used for a symbol that will later be exported, causing an error; a local
symbol might be accessed where a symbol that will later be imported or
inherited was intended. These problems can be difficult to understand
or even to recognize, are difficult to recover from without completely
restarting the Lisp, and give Common Lisp a bad name.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. It encourages putting the
entire definition of a package in a single place. It also encourages
putting all the package definitions of a program in a single file, which
can be loaded before loading or compiling anything that depends on those
packages. This file can be read in the USER package, avoiding any
package bootstrapping issues.
In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Also expand MAKE-PACKAGE and IN-PACKAGE to take all the same keyword
arguments as DEFPACKAGE, for consistency.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is a list of a keyword and arguments. Nothing in a
DEFPACKAGE form is evaluated.
package-name is a symbol or a string; if a symbol, only its name
matters, not what package it is in. If a string, capitalization
matters, normally uppercase is used.
Standard options for DEFPACKAGE are listed below. Additional options
might be present in an implementation, and each implementation must
signal an error if an option not recognized by that implementation is
present. Additional implementation-dependent options might take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.
Each option may appear at most once. If duplicate options are present,
DEFPACKAGE signals an error.
(:EXPORT {symbol}*)
Create symbols with the specified names and export them.
Note that only the name of each argument symbol is used.
The symbol that gets exported is not necessarily the one given
as an argument; it's a symbol with that name but in the package
being defined.
(:IMPORT {symbol}*)
Import the specified symbols.
(:IMPORT-FROM {(package-name {symbol}*)}*)
(:IMPORT-FROM package-name {symbol}*)
Find the specified symbols in the specified packages and import
them into the package being defined. The second syntax is a
convenient abbreviation when only one package is specified.
Note that only the name of each argument symbol is used. The
actual symbol that gets imported is not necessarily the one
given as an argument; it's a symbol with that name accessible in
the named package.
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified strings.
(:SHADOW {symbol}*)
Create the specified symbols in the package and place them on
the shadowing list. Note that only the name of each argument
symbol is used.
(:SHADOWING-IMPORT {symbol}*)
Import the specified symbols into the package and make them
shadow any inherited symbols.
(:SHADOWING-IMPORT-FROM {(package-name {symbol}*)}*)
(:SHADOWING-IMPORT-FROM package-name {symbol}*)
Find the specified symbols in the specified packages and import
them into the package being defined, making them shadow any
inherited symbols. The second syntax is a convenient
abbreviation when only one package is specified. Note that only
the name of each argument symbol is used. The actual symbol
that gets imported is not necessarily the one given as an
argument; it's a symbol with that name accessible in the named
package.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
(:USE {package}*)
Inherit from the specified packages.
Example:
(DEFPACKAGE MY-PACKAGE
(:USE LISP)
(:SHADOW CAR CDR CONS)
(:NICKNAMES MYPKG MY-PKG))
Rationale:
See first paragraph of Proposal section.
Current practice:
Symbolics Common Lisp has always had this, and uses it in preference
to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL version
of DEFPACKAGE has quite a few additional options, but none of them
appear to be necessary to propose for Common Lisp at this time.
Cost to Implementors:
Should be small as the macro can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
The "Put in seven extremely random user interface commands" business
described at the end of chapter 11 could be removed, and the special
compiler handling of these functions necessary to support that could be
removed. As this would be an incompatible change, it is not part of
this proposal.
KMP suggests that IN-PACKAGE should be incompatibly changed only to
recognize existing packages, not to create them, which would fix a lot
of bugs. IN-PACKAGE would then not accept any keyword arguments.
Moon thinks this is a reasonable idea but should be the subject of a
separate proposal.
∂08-Jun-88 1946 X3J13-mailer Issue: FUNCTION-CALL-EVALUATION-ORDER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 19:46:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 19:45:16 PDT
Date: 8 Jun 88 19:44 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-CALL-EVALUATION-ORDER (Version 1)
to: X3J13@Sail.Stanford.Edu
reply-to: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <880608-194516-3779@Xerox>
The only discussion on this issue was a revisiting of the various hiding places
in CLtL where it states requirement that function arguments evaluate from
left to right.
!
Issue: FUNCTION-CALL-EVALUATION-ORDER
References: CLtL p 194 ("...that order is always left to right")
Category: CLARIFICATION
Edit history: Version 1 by Clinger (22 March 1988)
Problem Description:
CLtL does not say whether the function expression of a call is evaluated
before or after the argument expressions.
Proposal (FUNCTION-CALL-EVALUATION-ORDER:UNSPECIFIED):
Common Lisp does not specify whether the function expression of a call is
evaluated before or after the argument expressions. Programs that rely on
a particular order of evaluation are in error.
Example:
(defun foo (x) (+ x 3))
(defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4))))
(foo (progn (bar) 20))
; may return 23 or 24
Rationale:
This makes the status quo explicit.
Current Practice:
TI and Symbolics evaluate the function expression last. Lucid and Coral
sometimes evaluate the function expression first and at other times evaluate
the function expression last.
Cost to implementors:
None.
Cost to users:
None.
Benefits:
Codifies an ambiguity.
Aesthetics:
Since Common Lisp evaluates argument expressions from left to right, it would
be more consistent for the function expression to be evaluated before the
argument expressions. On the other hand, the evaluation rules for function
expressions are already quite different from the rules for argument
expressions, and nobody in their right mind would write code that depends on
the order of evaluation, so aesthetics should not count for much in this case.
Requiring left to right evaluation would force some implementations to consume
an extra register for many function calls. The efficiency argument seems more
important than the aesthetic argument.
∂08-Jun-88 1958 X3J13-mailer Issue: LAST-N (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 19:58:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 19:57:18 PDT
Date: 8 Jun 88 19:57 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: LAST-N (Version 2)
To: x3j13@SAIL.Stanford.EDU
cc: masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-195718-3790@Xerox>
!
Issue: LAST-N
References: LAST (p267)
Category: ENHANCEMENT
Edit history: 04-Dec-87, Version 1 by Pitman
12-Mar-88, Version 2 by Pitman
Problem Description:
People always ask why LAST returns a cons and not an element.
BUTLAST takes an argument N but LAST does not.
Proposal (LAST-N:ALLOW-OPTIONAL-ARGUMENT):
Allow LAST to take an optional argument N, saying how many cells to return.
The default for N would be 1.
It is an error if N is negative or L is circular.
If N is zero, then the atom that terminates the list L is returned.
If N is greater than or equal to the number of cons cells in the list
L, then the result is L.
Test Cases:
(LAST '(A B C) 0) => ()
(BUTLAST '(A B C) 0) => (A B C)
(LAST '(A B C) 1) => (C)
(BUTLAST '(A B C) 1) => (A B)
(LAST '(A B C) 2) => (B C)
(BUTLAST '(A B C) 2) => (A)
(LAST '(A B C) 3) => (A B C)
(BUTLAST '(A B C) 3) => ()
(LAST '(A B C) 4) => (A B C)
(BUTLAST '(A B C) 4) => ()
(LAST '(A B C)) => (C)
(BUTLAST '(A B C)) => (A B)
(LAST '(A . B) 0) => B
(LAST '(A . B) 1) => (A . B)
(LAST '(A . B) 2) => (A . B)
Rationale:
BUTLAST and LAST would select complementary parts of a list in general.
That is (EQUAL L (APPEND (BUTLAST L N) (LAST L N))) would be T for N >= 0
and L being a proper list.
This would make it more obvious why LAST should return a list and not
an element. ie, it would return the "last N elements" where N=1 by default.
Current Practice:
Probably nobody does this.
Adoption Cost:
Very slight. The following code would suffice:
(DEFUN LAST (LIST &OPTIONAL (N 1))
(CHECK-TYPE N (INTEGER 0))
(DO ((L LIST (CDR L))
(R LIST)
(I 0 (+ I 1)))
((ATOM L) R)
(IF (>= I N) (POP R))))
Some implementations might want to provide compiler optimizations for
the N=1 case.
Benefits:
This utility is probably needed often enough to warrant its inclusion.
It's present (as a separate function called NLEFT) in Symbolics Common
Lisp and Interlisp.
Conversion Cost:
None. This is an upward compatible extension.
Aesthetics:
This would make things a little prettier.
Discussion:
This suggestion came up recently on a Symbolics design discussion list.
Symbolics is contemplating offering it as an extension, but it seemed like
the rest of the CL community might want to adopt it, too. Pitman thinks
it's a nice idea.
Masinter opposes this extension as gratuitous.
Moon and Daniels think this is very low priority but have expressed a
lack of major objection to this proposal.
∂08-Jun-88 2030 X3J13-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 20:30:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 20:29:25 PDT
Date: 8 Jun 88 20:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION
to: X3J13@Sail.stanford.edu
cc: masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-202925-3823@Xerox>
This draft is for discussion at the June 1988 X3J13 meeting.
!
Status: DRAFT
Issue: HASH-TABLE-PRINTED-PREPRESENTATION
Category: ENHANCEMENT
Edit history: 23-May-88, Version 1 by Touretzky
8-Jun-88, Version 2 by Masinter (as per cl-cleanup discussion)
Description:
Hash tables are currently second-class data structures when compared to
lists, vectors, and structures, because they have no READable printed
representation. This proposal introduces a #H reader syntax for hash
tables and a switch to control when hash tables will be printed this way.
Proposal (HASH-TABLES-PRINTED-REPRESENTATION:#H-NOTATION) :
1) Introduce the following reader notation for hash tables:
#nH(type (k1 v1) (k2 v2) ...)
"n" is the size of the table; it is analagous to the :size argument to
MAKE-HASH-TABLE. If omitted, the system picks some reasonable size.
"type" is one of EQ, EQL, or EQUAL. If omitted it defaults to EQL.
The (ki vi) pairs consist of a key and a value. There may be any number of
such pairs, including zero. Order is not significant. It is an error for
two keys to be identical (using the EQ, EQL, or EQUAL test, as
appropriate.)
2) Introduce a switch called *PRINT-HASH* whose initial value is
implementation-dependent. If *PRINT-HASH* is T, hash tables are printed
using the #H syntax (with all optional components supplied), subject to the
usual limits imposed by *PRINT-LEVEL* and *PRINT-LENGTH*. If *PRINT-HASH*
is NIL, hash tables are printed using the current #<HASH-TABLE ...> syntax.
Rationale:
This is a useful upward compatible extension (except in
implementations that have usurped #H for other purposes), with very
low adoption cost.
Cost to Implementors:
A simple change to PRIN1 and the pretty printer. Most of the code
will be similar to existing routines for printing vectors in #()
notation and arrays in #nA() notation. The reader would change to
read this notation.
Cost to Users:
Small. Programs that want to control all *PRINT- parameters will need
to know about yet another parameter.
Benefits:
This proposal makes hash tables first class objects. If
*PRINT-HASH* is T, their contents become visible in all the normal ways,
e.g., if FOO is bound to a hash table object, then typing FOO to a
read-eval-print loop will display the contents of the hash table. Hash
table contents may also be displayed by TRACE if the table is passed as an
argument; they may also be displayed by the debugger. Finally, hash tables
may be appear as literal objects in programs and be read or written to files.
Current practice:
We know of no current implementations of this proposal.
Although some implementations allow the user to see hash table contents
with DESCRIBE or INSPECT, not all do. CMU Common Lisp's DESCRIBE, for
example, does not show hash table contents. This reinforces the need for
a standard #H notation to guarantee that users can manipulate a hash table
as easily as a vector, array, or structure.
Discussion:
Several alternatives have been suggested for the syntax of #H.
- preferred notation: #H(EQL (FOO 37) (BAR 42))
- dotted pair notation: #H(EQL (FOO . 37) (BAR . 42))
- property list: #H(EQL FOO 37 BAR 42)
- pseudo-structure: #S(HASH-TABLE TYPE EQL SIZE 20 INITIAL-CONTENTS ((FOO 37) (BAR 42)))
One problem with the currently proposed #H notation is that it provides no
way to specify a rehash-size or rehash-threshold. This should not be a
fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is also
shared by #nA notation. Some object that the fact that #A is flawed is no
reason to introduce the same flaw elsewhere.
This prompted yet another proposal:
#[size]H([type] [rehash-size] [rehash-threshold] (ki vi)*)
e.g. #65H(EQL 101 65 (FOO 37) (BAR 42))
along with alternative settings for *PRINT-HASH*, NIL, T, :BRIEF, where the
latter would leave out all of the options.
∂08-Jun-88 2049 X3J13-mailer Issue: MACRO-FUNCTION-ENVIRONMENT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 20:49:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 20:48:16 PDT
Date: 8 Jun 88 20:47 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: MACRO-FUNCTION-ENVIRONMENT
To: x3J13@SAIL.Stanford.Edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-Cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-204816-3838@Xerox>
!
Issue: MACRO-FUNCTION-ENVIRONMENT
References: MACRO-FUNCTION, p. 144
MACROLET, pp. 113-4
&ENVIRONMENT, pp. 145-6
MACROEXPAND and MACROEXPAND-1, pp. 151-2
Category: ADDITION
Edit history: Version 1, Pavel, March 21, 1988
Version 2, Masinter, 8-Jun-88, (as per cleanup discussion)
Problem description:
The &ENVIRONMENT argument to a macro-expansion function may only be used as the
second argument to the functions MACROEXPAND and MACROEXPAND-1. It is sometimes
more convenient, however, to be able to work directly with the more primitive
function MACRO-FUNCTION, on which MACROEXPAND and MACROEXPAND-1 are presumably
based. However, since MACRO-FUNCTION does not take an environment argument, it
cannot be used in situations in which that environment must be taken into
account.
Proposal (MACRO-FUNCTION-ENVIRONMENT:YES):
Add an optional second argument to MACRO-FUNCTION, that argument being an
environment that was passed as the &ENVIRONMENT argument to some macro expansion
function. If the argument is not given, or the argument is NIL, the null
environment is used. MACRO-FUNCTION will now consider macro definitions from
that environment in preference to ones in the global environment. It is an error
to supply the environment argument in a use of MACRO-FUNCTION as a SETF location
specifier.
Examples:
(macrolet ((foo (&environment env)
(if (macro-function 'bar env)
''yes
''no)))
(list (foo)
(macrolet ((bar () :beep))
(foo))))
=> (no yes)
(setf (macro-function 'bar env) ...) is an error.
Rationale:
Intuitively, the more primitive operation in macro expansion is MACRO-FUNCTION,
not MACROEXPAND or MACROEXPAND-1, yet the environment argument can only be
supplied to the latter functions and not to the former one. By changing this
state of affairs, the model of macro expansion becomes somewhat simpler. Also,
more flexible use of the facility is enabled.
Current practice:
Xerox Common Lisp already implements this proposal. Symbolics Common Lisp,
and Kyoto Common Lisp do not. Lucid Common Lisp did not, but version 3.0 does.
Cost to Implementors:
This is presumably a simple change to make, a small matter of moving the
environment-searching code from MACROEXPAND-1 to MACRO-FUNCTION.
Cost to Users:
The change is upward-compatible and so poses no cost to users.
Cost of non-adoption:
One more (small) semantic wart on the language.
Benefits:
The function that users think of as being more primitive really is.
Aesthetics:
This slightly cleans up the language.
Discussion:
This issue was discussed starting in January 1987, but got tangled in
a web of other related proposals. In its current form, the only objections
have been that some other proposal or committee might otherwise change
macro handling, or that this proposal doesn't fix enough of the problems.
∂08-Jun-88 2058 X3J13-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 20:57:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 20:57:13 PDT
Date: 8 Jun 88 20:57 PDT
From: Masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Subject: Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
line-fold: no
Message-ID: <880608-205713-3851@Xerox>
!
Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE
References: CLtL, pages 331, 386
Category: CLARIFICATION
Edit history: Version 1, 25-Mar-88 JonL
Version 2, 29-Mar-88 JonL (fix typos; comments by Daniels)
Version 3, 23-May-88 JonL (fix nits raised by Masinter)
Version 4, 23-May-88 JonL (change issue name -- only 1 proposal)
Version 5, 7-Jun-88 Masinter (more nits)
Problem description:
CLtL p386 says that FORMATting to a fill-pointer'd string should add
characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that
WITH-OUTPUT-TO-STRING will work "as if using VECTOR-PUSH-EXTEND if the
string is adjustable, and otherwise as if using VECTOR-PUSH". It's very
unlikely that the original authors of these parts intended differing
semantics for these two cases. Furthermore, the semantics for
WITH-OUTPUT-TO-STRING permit the inconspicuous loss of characters
written to the string, since VECTOR-PUSH will just "drop on the floor"
any characters that would go beyond the end.
Proposal (WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND):
Change the documentation of WITH-OUTPUT-TO-STRING to be like that under
FORMAT. That is, replace the first sentence of the next-to-last paragraph
on CLtL p331 by:
"If *string* is specified, it must be a string with a fill pointer;
the output is incrementally appended to the string (as if by use of
VECTOR-PUSH-EXTEND)."
Test Case:
(let ((str (make-array 4 :element-type 'string-char :fill-pointer 0)))
(with-output-to-string (s str) (princ "You Luz, Bunkie!" s))
str)
CLtL behaviour will return "You "; proposed behaviour will signal an error.
Rationale:
It's unlikely that the mention of VECTOR-PUSH in CLtL p331 was intended
to suggest that characters could be quietly "dropped on the floor". In
any case, there is no practical or theoretical reason to make FORMAT and
WITH-OUTPUT-TO-STRING act differently on non-adjustable strings.
Current Practice:
VaxLisp 2.2 and Lucid 3.0 implement the proposal; Lucid 2.1 and earlier
versions implement CLtL. For WITH-OUTPUT-TO-STRING, Xerox Common Lisp
implements CLtL. Symbolics Genera 7.2 implements the proposal.
Cost to Implementors:
Very small.
Cost to Users:
Virtually none.
Benefits:
Less special-casing in the semantics of "printing" to strings.
More conformity with naive expectations about printing to strings.
Aesthetics:
Minor impact.
Discussion:
Implementations may want to actually call VECTOR-PUSH, rather than
VECTOR-PUSH-EXTEND, on non-adjustable string in order to test the
result -- nil means an overflow of the total length of the string;
thus they may signal an error more directly related to the problem,
rather than permitting VECTOR-PUSH-EXTEND to complain about a non-
adjustable array. But either way, the semantics is still that of
VECTOR-PUSH-EXTEND: when you get to the end of the string, adjustable
strings are extended, and non-adjustable strings cause error signals.
It's perfectly acceptable to use VECTOR-PUSH-EXTEND with a non-adjustable
array. It's the error-signalling property of VECTOR-PUSH-EXTEND, as opposed
to the "dropping on the floor" of VECTOR-PUSH, that motivated this proposal.
∂08-Jun-88 2103 X3J13-mailer Issue SUBSEQ-OUT-OF-BOUNDS, version 2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 21:02:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 21:02:13 PDT
Date: 8 Jun 88 21:01 PDT
From: Masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Subject: Issue SUBSEQ-OUT-OF-BOUNDS, version 2
reply-to: cl-cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-210213-3853@Xerox>
!
Issue: SUBSEQ-OUT-OF-BOUNDS
References: :START and :END arguments (246-247), SUBSEQ (248)
Category: CLARIFICATION
Edit history: 24-Mar-88, Version 1 by Steele
29-Mar-88, Version 2 by Steele, in response to Moon's comments
Problem description:
The descriptions of :START and :END arguments, and of SUBSEQ, do not
explicitly address the question of out-of-bounds indices. (The language on
page 246, "These arguments should be integer indices into the sequence," is
considered too vague on this point.)
Also, the language on page 246 does not make clear whether the prohibition
against "start > end" applies to defaulted values as well as explicit
values, and does not specify clearly whether the default value for the
end argument is the allocated length or the active length.
Proposal (SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR):
Specify that it is an error for the :START argument of any standard
function, or the second argument to SUBSEQ, to be less than zero.
Specify that it is an error for the :END argument of any standard function,
or the third argument to SUBSEQ, to be greater than the active length of
the sequence in question (as returned by LENGTH).
Specify that the start value, after defaulting, must not be greater than
the end value, after defaulting.
Specify that the default value for the end argument is the active length of
the sequence in question.
This may be summarized as follows:
Let X be the sequence within which indices are to be considered. Let S be
the :START argument of any standard function, or the second argument to
SUBSEQ, whether explicitly specified or defaulted, through omission, to
zero. Let E be the :END argument of any standard function, or the third
argument to SUBSEQ, whether explicitly specified or defaulted, through
omission or an explicitly passed NIL value, to the active length of X, as
returned by LENGTH. It is an error if the condition (<= 0 S E (LENGTH X))
is not true.
Test Cases/Examples:
(SUBSEQ "Where's the beef?" -1 5) might be assumed to be "Where" or " Where".
(SUBSEQ "Where's the beef?" -3 -3) might be assumed to be "".
(SUBSEQ "Where's the beef?" 16 18) might be assumed to be "?" or "? ".
(SUBSEQ "Where's the beef?" 10000 10000) might be assumed to be "".
Under this proposal each of these situations is an error, and portable
programs may not rely on their behavior.
Rationale:
We don't want code indexing off the ends of arrays.
Current practice:
KCL interpreted and compiled code signals an error.
Symbolics Common Lisp interpreted and compiled code signals an error; the
compiler also issued an out-of-range warning (possible because the
arguments were all constant).
Lucid Common Lisp interpreted and compiled code signals an error.
Cost to Implementors:
None.
Cost to Users:
Users who depended on some specific implementation behavior in these cases
may find that their pragmatically unportable code is now officially
unportable.
Cost of non-adoption:
Confusion.
Benefits:
Removal of a small but important ambiguity in the spec.
Esthetics:
It seems cleaner not to allow indexing off the end of an array, and
by extension not allow it for any sequence.
Discussion:
This merely clarifies the original intent of the passage on page 246.
∂09-Jun-88 0714 CL-Cleanup-mailer Issue: LAST-N (Version 2)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 9 Jun 88 07:14:29 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 9 Jun 88 10:11:00 EDT
Received: by kali.think.com; Thu, 9 Jun 88 10:10:57 EDT
Date: Thu, 9 Jun 88 10:10:57 EDT
From: gls@Think.COM
Message-Id: <8806091410.AA03128@kali.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: Masinter.pa@xerox.com's message of 8 Jun 88 19:57 PDT <880608-195718-3790@Xerox>
Subject: Issue: LAST-N (Version 2)
I cast a "grue" vote for LAST-N:ALLOW-OPTIONAL-ARGUMENT; that is,
I support it and will continue to support it until it has consumed
either ten more messages on this mailing list or ten minutes of
meeting time, after which I will fiercely oppose it.
--Guy
∂09-Jun-88 0907 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jun 88 09:03:36 PDT
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa02943; 9 Jun 88 10:01 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa07565;
9 Jun 88 10:00 BST
To: cl-cleanup@sail.stanford.edu
CC: x3j13@sail.stanford.edu, masinter.pa@xerox.com
In-reply-to: Masinter.pa@com.xerox's message of 8 Jun 88 15:07 PDT <880608-150925-3305@Xerox>
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
Date: Thu, 9 Jun 88 10:02:42 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
>>Rationale:
>>
>>Since it would be difficult to prescribe reasonable behavior for
>>this situation, it should be considered an error. Checking for it
>>would be costly so signaling this error is not required.
Sorry, I do not see the great cost. Surely defstruct is in effect a
declaration, and the cost of checking is small and the value great.
==John
∂09-Jun-88 1043 X3J13-mailer [bouzane@scrc-pegasus: X3J13 Meeting]
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 10:43:22 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 10:42:22 PDT
Received: from challenger.lucid.com by edsel id AA14871g; Thu, 9 Jun 88 10:37:09 PDT
Received: by challenger id AA12537g; Thu, 9 Jun 88 10:34:58 PDT
Date: Thu, 9 Jun 88 10:34:58 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8806091734.AA12537@challenger.lucid.com>
To: x3j13@sail.stanford.edu
Subject: [bouzane@scrc-pegasus: X3J13 Meeting]
We only have 34 people registered for X3J13 in Boston. Rosemary needs to know
how many will be at lunches. Please let her know if you will be attending but
haven't let her know yet. If you are unable to reach her please conact me and
I will pass on the information.
---jan---
Registered Attendees:
Arbaugh, William - US Army
Antonisse, H. James - Mitre Corp.
Bartley, David - Texas Instruments
Beiser, Paul - Hewlettt & Packard
Boelk, Mary P. - Johnson Controls
Chapman, Kathy - Digital
Dabrowski, Chris - Nat'l Bureau of Standards
DeMichiel, Linda - Lucid
Dussud, Patrick - TI
Gabriel, Dick - Lucid
Hadden, George, Honeywell
Haflich, Steve - Franz, Inc.
Hewitt, Carl - MIT AI Lab
Keene, Sonya E. - Symbolics, Inc.
Kiczales, Gregor - Xerox Parc
Larson, Aaron - Honeywell
Linden, Thomas - IBM Almaden Research
Loosemore, Sandra - Evans & Sutherland
Mathis, Robt.
Mikelsons, Martin - IBM
Moon, David A. - Symbolics, Inc.
Perdue, Crispin - Sun
Pierson, Dan - Encore
Piazza, Jeffrey - Digital
Rand, Douglas - Prime Computer
Rosenking, Jeff - Grumman Corp
Saji, Nobuyuki - NEC Corp
Slater, David - Computer Sciences Corporation
Van Roggen, Walter - Digital
Van Deusen, Mary - TI
Waldrum, Ellen - Texas Inst.
White, Jon - Lucid
Zubkoff, Jan - Lucid
∂09-Jun-88 1525 X3J13-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 15:25:08 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 15:24:07 PDT
Received: from bhopal.lucid.com by edsel id AA16555g; Thu, 9 Jun 88 15:19:42 PDT
Received: by bhopal id AA25468g; Thu, 9 Jun 88 15:18:17 PDT
Date: Thu, 9 Jun 88 15:18:17 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806092218.AA25468@bhopal.lucid.com>
To: Masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu, labrea!cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 12:39 PDT <880608-123958-2954@Xerox>
Subject: Issue: DECLARATION-SCOPE (Version 2)
Did you really want to distribute this to the X3J13 committee as a whole?
I had proposed a major rewrite of this issue, based on treating DECLARE
simply as a lexical construct, but haven't had the time to work on it before
the upcoming meeting. I'd hoped to see cleanup subcommittee discuss it
again before bringing the issue to the committee as a whole.
-- JonL --
∂09-Jun-88 2119 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 21:19:30 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 21:17:29 PDT
Received: from bhopal.lucid.com by edsel id AA17893g; Thu, 9 Jun 88 21:10:37 PDT
Received: by bhopal id AA26479g; Thu, 9 Jun 88 21:09:17 PDT
Date: Thu, 9 Jun 88 21:09:17 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806100409.AA26479@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: x3j13@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 17:47 PDT <880608-174735-3615@Xerox>
Subject: Issue: EQUAL-STRUCTURE (Version 2)
I thought you were going to incorporate my comments into this issue, which
I sent in reply to its first presentation:
Date: Fri, 18 Mar 88 21:21:51 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Fri, 18 Mar 88 17:39 EST <880318173922.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 1)
Generally ok write-up of the issues. You left out the option of adding
a jillion-skillion new functions -- one for each conceivable kind of
equivalence relation between s-expressions. But that's ok; I want to
focus on just one of your proposals.
re: Proposal (EQUAL-STRUCTURE:DESCEND):
Change EQUAL and EQUALP to descend structure slots.
EQUALP is already documented to descend structures (CLtL, p81). So this
proposal should just say "Change EQUAL ...".
Had all the negative arguments against this particular proposal -- the one
you call (EQUAL-STRUCTURE:DESCEND) -- been thought of 6 years ago, CL could
not even have an EQUALP function. The logical conclusion of these
"technical details" arguments is that EQUAL cannot be defined either.
These arguments go roughly as follows:
(1) The equivalence which EQUAL implements is not graph-isomorphism --
which *is* uniquely defined -- but rather an ill-defined one
making reference to the underspecified notion of "printing".
Attempts to make it more precise are merely arbitrary.
(2) EQUAL is not a total function since it is permitted to run amok
on circular structures. In fact, it is much more "likely" that
defstruct instances will contain ultimately circular links than
that cons cells will; hence one will "probably" lose more much
often if EQUAL were to descend structures.
The more "wizard", or "theorist" one is, the more compelling the above
arguments seem. On the other hand, the more a "user" one is, the more
likely he will argue as follows:
I've used the EQUAL function for over 15 years, and have almost never
been dissatisfied with it, as the Doctors of Technology say I should be;
and every instance of dissatisfaction was due to its failue to descend
through pointer vectors. I keep my house in order, and know exactly
how my data pyramids are built up; so why should I be punished just
because some Conehead somewhere got lost playing around with his
Klein bottles and Moebius strips?
All the problems alleged for EQUALP's descent into structures also apply
to EQUAL's descent into lists; it's only a matter of probabilities. Hence,
I don't believe this issue can be settled by technical discussion.
The only non-time-wasting effort I can see to do from now on is to look for
some way to present our dilemma to a broad "user" community. We could try
to tell them, in cursory terms and few words, of the technical arguments
that show EQUAL (and EQUALP) to be ill-behaved functions. Then let them
decide (by straw vote?) if the extra functionality provided by this proposal
is worth the extra risk.
Related Issues:
-- Are DEFSTRUCT-defined types and CONS, ARRAY, HASH-TABLE, PACKAGE,
READTABLE, STREAM, etc. pairwise disjoint?
-- Will CLOS require EQUAL to be "generic"? Also, what about COPY?
-- JonL --
∂09-Jun-88 2136 X3J13-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 21:36:23 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 21:34:39 PDT
Received: from bhopal.lucid.com by edsel id AA18027g; Thu, 9 Jun 88 21:27:54 PDT
Received: by bhopal id AA26522g; Thu, 9 Jun 88 21:26:35 PDT
Date: Thu, 9 Jun 88 21:26:35 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806100426.AA26522@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 20:24 PDT <880608-202925-3823@Xerox>
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION
Touretzky actually said he would alter his proposal to account for the
:rehash-size and :rehash-threshold omissions; but this version of the
proposaldoesn't show that. I remember remarking that you still can't
call the objects "first class" if the printed representation cannot be
read in as an equivalent copy; and the fact that CL has some other datatypes
that aren't "first class" doesn't argue for doing something substandard
for hash-tables. I don't seem to have a copy of the mail from Dave in
which he said he would alter his proposal.
Date: Mon, 23 May 88 15:37:48 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
To: labrea!Dave.Touretzky@CS.CMU.EDU
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Mon, 23 May 88 11:27:58 EDT <361.580404478@DST.BOLTZ.CS.CMU.EDU>
Subject: HASH-TABLE-PRINTED-REPRESENTATION
re: One problem with the currently proposed #H notation is that it provides
no way to specify a rehash-size or rehash-threshold. This should not be
a fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is
also shared by #nA notation.
I think this is a fatal flaw. The fact that *some* complex classes of
arrays also share this fatal flaw is no argument for retaining it. It
is still the case that simple arrays of the more common element types
do not have the flaw; and several years ago there was some discussion
on how to fix other manifestations of the flaw on multi-dimensional arrays.
-- JonL --
∂09-Jun-88 2307 X3J13-mailer Issue status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jun 88 23:07:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 88 23:05:43 PDT
Date: 9 Jun 88 23:05 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue status
To: x3j13@Sail.stanford.edu
Message-ID: <880609-230543-6121@Xerox>
For this meeting, I have been broadcasting those issues where either:
a) there has been convergence within the cleanup committee and the issue is
ready for voting by X3J13 or,
b) there has not been any mail in the cleanup committee on the issue for a
significant period of time, even when there have been additional significant
remarks.
I've tried to mark the issues in the latter status as DRAFT, the idea being that
you have some idea of what other significant issues remain before the cleanup
committee, and might have some comments or contributions that will guide our
deliberations. I hope you will understand that the issues for this meeting are
not as uniformly "baked" as our previous submissions.
There are a number of thorny issues that have been in committee for a long time
(some for well over a year); as time goes on, it becomes less useful to attempt
to postpone them to the "next" X3J13 meeting, especially given the schedule for
a draft standard.
I have a number of other issues to mail out; they will be followed by a list of
all of the issues mailed.
Thanks,
Larry
∂10-Jun-88 0056 X3J13-mailer Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 00:56:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 00:55:18 PDT
Date: 10 Jun 88 00:54 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 4)
To: x3j13@SAIL.STANFORD.EDU
line-fold: no
cc: Masinter.pa@Xerox.COM
REPLY-TO: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <880610-005518-6180@Xerox>
!
Issue: SHARPSIGN-PLUS-MINUS-NUMBER
References: #+ (p358), #- (p359), *features* (p448),
Parsing of Numbers and Symbols (p339-342)
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE
Category: ENHANCEMENT
Edit history: Version 1 by Pitman 03/01/87,
Version 2 by Pitman 03/09/87 (address potential numbers)
Version 3 by Masinter 23-May-88, revive
Version 4 by Masinter 10-Jun-88, fix nits
Problem Description:
Features which are not symbols are currently not allowed.
Unfortunately, machine names are used as features. Since
some machines are named only by a number (eg, 360, 3600, 8600,
8080, ...) there is no way to use these names as features.
Alternate, less mnemonic feature names, must be contrived.
`Potential numbers' (as described on p341) should be addressed
specifically if only to say that they are still illegal. There
should be no ambiguity about what is legal and what is not.
An example of such a symbol is 68020A .
Proposal (SHARPSIGN-PLUS-MINUS-NUMBER:OK)
Extend the definition of #+ and #- on pp358-359 to say that
integers are allowable as features. Define that the feature-spec
reader binds base to 10 so that people don't have to do #+7020 to
find the 3600 feature in base 8.
In the case of `potential numbers' (as per p341) in a feature
spec, say that they are allowed for use in this context. If the
implementation does not support the syntax in question, it is
permitted to treat the syntax as if it denoted a feature which
was known not to be present. That is, in any implementation where
a potential number which is denoted by a character sequence <X> can
be parsed by the reader as either a number or a symbol, then
#+<X> will skip the next form iff the expression
(MEMBER (LET ((*READ-BASE* 10.)
(*PACKAGE* (FIND-PACKAGE "KEYWORD")))
(READ-FROM-STRING "<X>"))
*FEATURES*)
yields false, without prejudice to decision about whether <X>
denotes a number or a symbol. If <X> cannot be read by the reader
because it is a potential number, then #+<X> will skip the next
form as if any feature <X> might have been intended to denote was
not present.
Extend the definition of *features* on p448 to say that it is a
"list of symbols and/or numbers".
Comparison is performed by EQL.
Rationale:
There is no deep-rooted reason why numbers shouldn't work.
The current restrictions are somewhat arbitrary. This would
allow arbitrary alphanumeric strings (subject to restrictions
about potential numbers) to be used as identifiers in a
well-defined way.
Current Practice:
Some implementations already allow this (though most probably
do not bind base to 10 -- I've seen some octal feature names).
Other implementations signal an error if they see what they
believe to be an invalid feature name (such as a number).
Cost to implementors:
Changes to implementations not already supporting this feature
would probably be very minor.
Cost to Users:
Some users would view this as an enhancement; others as a bug fix.
I don't think it would be seen in a negative light.
Benefits:
A restriction which seems arbitrary to some people would be removed.
Aesthetics:
No issues not already addressed above.
Discussion:
Pitman initiated this proposal and thinks that it would be a
worthwhile extension.
Steele asks about treatment of potential numbers, such as #+68020a .
Revision 2 of this proposal addresses that issue, by explicitly
stating that this is allowed.
Fahlman reluctantly supported version 1 of this proposal since
some implementations support numbers here and since the purpose of
this feature is to allow selection of such implementations. He
wishes people would write Symbolics-3600 rather than 3600 since it
isn't clear that 3600 is meaningful in the abstract. He wants to
see the potential number issue treated, however.
KMP thinks that the problem of meaningfulness is not unique
to numbers. Many feature names with only alphabetic characters
could be likewise criticized. In practice, brevity is important
because AND and OR will greatly increase horizontal size of
feature-spec expressions and often it's desirable to still have
enough room to the right to grind the conditionalized expression.
Dick Gabriel opposed this proposal: "unless there is a compelling
reason to do otherwise, it is best to have as few different rules and
concepts in a language as possible.
Let `#+' represent either `#+' or `#-'. Currently #+<object> can be such
that <object> is a symbol or a boolean expression. I don't see any gain in
expressive power if we extend this to include numbers, yet we've extended
the complexity of the language a little bit.
Furthermore, the examples given are not compelling at all - someday soon
some people will not know what I mean when I say I mailed this message
from a 10.
Symbolics-3600, IBM-360, MC68020A - these are proper machine names and
hence proper feature names.
Finally, an expression like #-3600 looks like an arithmetic expression
or a slip of the TIP for simply -3600."
∂10-Jun-88 0107 X3J13-mailer Issue: SPECIAL-VARIABLE-TEST (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 01:07:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 00:59:37 PDT
Date: 10 Jun 88 00:59 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: SPECIAL-VARIABLE-TEST (Version 2)
To: x3j13@SAIL.STANFORD.EDU
cc: masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@SAIL.STANFORD.EDU
line-fold: no
Message-ID: <880610-005937-6183@Xerox>
!
Issue: SPECIAL-VARIABLE-TEST
References: Declaring Global Variables and Named Constants (pp68-69),
Declaration Specifiers (p157)
Category: ADDITION
Edit history: 07-Mar-88, Version 1 by Pitman
21-May-88, Version 2 by Pitman (correct test case, add discussion)
Problem Description:
CLtL does not define a way to test to see if a variable has been
proclaimed special (for the purposes of either binding or reference).
Programs such as macros, code-walkers, and program-generating programs
may need such information from time to time in order to do certain kinds
of reasoning about code-motion, unused variables, etc.
Proposal (SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P)
Add a function SPECIAL-VARIABLE-P by analogy with SPECIAL-FORM-P
which is defined as:
SPECIAL-VARIABLE-P symbol &optional environment [Function]
Returns T iff -symbol- names a variable which is SPECIAL in the
indicated lexical -environment-. Otherwise, it returns NIL.
It is an error if -symbol- is not a symbol. If not supplied, the
-environment- defaults to NIL, meaning the null lexical environment.
This function will be useful in determining whether a reference to
the variable named by SYMBOL in the indicated ENVIRONMENT will be
a special reference.
Note: Since special variable proclamations are pervasive and
declarations are not, the technique for determining whether binding
the variable named by SYMBOL is not dependent on the surrounding
lexical environment. It is instead dependent only on the global
environment and on the declarations of the form which would accomplish
the binding. Whether the variable has been globally proclaimed special
can be determined by doing (SPECIAL-VARIABLE-P 'symbol). Whether the
variable is locally declared SPECIAL can be checked only by parsing
the declarations looking for (DECLARE ... (SPECIAL ... symbol ...)).
Test Case:
(PROCLAIM '(SPECIAL SPECIAL-FOO))
(MACROLET ((TEST (NAME &ENVIRONMENT ENV)
`'(,NAME ,(SPECIAL-VARIABLE-P NAME ENV)) ))
(LIST* (TEST SPECIAL-FOO) ;0
(TEST FOO)
(LET ((SPECIAL-FOO 1) (FOO 1))
(LIST* (TEST SPECIAL-FOO) ;1
(TEST FOO)
(LET ((SPECIAL-FOO 2) (FOO 2))
(DECLARE (SPECIAL FOO))
(LIST* (TEST SPECIAL-FOO) ;2
(TEST FOO)
(LET ((SPECIAL-FOO 3) (FOO 3))
(LIST (TEST SPECIAL-FOO) ;3
(TEST FOO)))))))))
=> ((SPECIAL-FOO T) (FOO NIL) ;0
(SPECIAL-FOO T) (FOO NIL) ;1
(SPECIAL-FOO T) (FOO T) ;2
(SPECIAL-FOO T) (FOO NIL)) ;3
Rationale:
This would allow programs that reason about other programs to obtain
important information about SPECIAL declarations and proclamations.
Current Practice:
Interpreters and compilers must, of necessity, have a way to do this
internally.
In some implementations, information about special variable proclamations
is kept on a symbol's plist, and users eventually "figure out" how to take
advantage of that.
In most implementations, getting information about special declarations
is neither documented nor easy to "figure out".
Symbolics Genera has undocumented internal function which does this.
Cost to Implementors:
By necessity, compilers and interpreters must have a way to get the
information returned by this facility. In general, it should just be
a matter of providing a program interface to that facility.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
Some code-walkers, macros, etc. would continue be hard to write in a
portable way.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Although SPECIAL variables provide some benefit to Common Lisp, that
benefit has not been without price. It's difficult to do proper code
analysis if lexical and special variables look the same. The presence
of this operator makes it easier to write code which reasons clearly
and correctly about other programs, and so will probably tend to
improve the aesthetics of such programs.
Discussion:
This proposal came to the Cleanup committee from the Japanese community.
Pitman wrote it up formally.
Pitman and Moon support SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P.
∂10-Jun-88 0108 X3J13-mailer Issue: STEP-ENVIRONMENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 01:08:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 01:07:49 PDT
Date: 10 Jun 88 01:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: STEP-ENVIRONMENT (Version 1)
To: x3j13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Reply-to: CL-CLEANUP@Sail.stanford.edu
Line-fold: NO
Message-ID: <880610-010749-6191@Xerox>
!
Issue: STEP-ENVIRONMENT
References: STEP (CLtL p.441)
TIME (CLtL p.441)
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 10-Jun-88, Masinter (add discussion)
Problem description:
CLtL does not specify in what lexical environment the form given to STEP
is evaluated. Some people think it's supposed to be evaluated in the
null environment, others think it is supposed to be evaluated in the
current environment, the one in which the STEP form was evaluated.
The same considerations apply to TIME.
An additional problem is that CLtL says that STEP is a macro. However,
it is unclear what portable expression the macro could expand into,
especially if STEP evaluates the form in the current environment. STEP
is really a variation of the Lisp interpreter, which makes it more like
a special form than like a macro.
The interaction of STEP with the compiler is not specified.
Proposal (STEP-ENVIRONMENT:CURRENT):
1. Clarify that STEP and TIME evaluate the form in the current environment.
2. Change STEP from a macro to a special form.
3. Clarify that it is an error to compile a STEP form.
Test Cases/Examples:
;Assuming X is not a special variable
(setq x 1)
(let ((x 2))
(step (print x)))
This should print and return 2, not 1, when interpreted.
Rationale:
1. It is more useful for the lexical environment to pass transparently
through STEP and TIME than to reset to the null environment.
2. STEP is really a variation of the Lisp interpreter, which makes it more
like a special form than like a macro.
3. As a debugging TOOL, STEP forms do not need to be compiled. It would
be difficult to specify precisely what should happen when a STEP form is
compiled (which parts of the form are to be executed interpretively), so
it's easier to duck the issue. Use "is an error" rather than "signals
an error" so that compile-only implementations are permitted to compile
STEP forms.
Current practice:
Symbolics Common Lisp behaves as proposed.
Cost to Implementors:
1 requires passing an environment around, which should be easy.
2 and 3 are just restrictions, so they should cost nothing.
Cost to Users:
None.
Cost of non-adoption:
These debugging tools will continue to have vague specifications.
Benefits:
Slightly more preicse specification of Common Lisp.
Esthetics:
Slightly improved.
Discussion:
There was some discussion of separating this out into two separate
proposals, but it didn't seem useful.
Eric Benson contributed the definition of TIME in Lucid Common Lisp:
(defmacro time (form)
`(time-internal #'(lambda () ,form)))
The function TIME-INTERNAL looks something like:
(defun time-internal (thunk)
(let ((before-time (get-time-state)))
(unwind-protect
(funcall thunk)
(print-time-information before-time (get-time-state)))))
The definition of STEP is similar. This is just to show that it is
easy to get the right lexical environment even though TIME and STEP
are macros.
∂10-Jun-88 0154 X3J13-mailer Issues for discussion at June 1988 X3J13 meeting
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 01:54:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 01:53:53 PDT
Date: 10 Jun 88 01:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Issues for discussion at June 1988 X3J13 meeting
TO: x3j13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
reply-to: cl-cleanup@sail.stanford.edu
Message-ID: <880610-015353-6228@Xerox>
The following issues are for discussion at the X3J13 meeting. Except for
FUNCTION-TYPE-REST-LIST-ELEMENT and SETF-FUNCTION-VS-MACRO, you
should have received copies of these.
Issues already discussed at previous meetings:
- FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3, 13-Feb-88)
(allow &rest <type> in function types to refer to element
type)
Released before. not remailed to X3J13 for the June meeting.
* FUNCTION-TYPE (Version 10, 22-May-88)
(Change definition of FUNCTIONP, function type ...)
Rewritten for X3J13/June 1988
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
Released before. not remailed to X3J13 for the June meeting.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
New issues for the June 1988 X3J13 meeting (some in DRAFT form):
* ADJUST-ARRAY-FILL-POINTER
(Interaction of Adjust-ARRAY and fill pointers.)
* DATA-TYPES-HIERARCHY-UNDERSPECIFIED (Version 1, 24-Mar-88)
( STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE are
required to be disjoint from other types)
* DECLARATION-SCOPE (Version 2, 2-Feb-88)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
*** DRAFT ***
* DEFPACKAGE (Version 2, 23-Mar-88)
(Add new DEFPACKAGE macro to handle common package operations.)
*** DRAFT ***
* DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1, 13-May-88)
(two slots in a single DEFSTRUCT can't have the same name)
* DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER (Version 1, 13-May-88)
(its OK to have zero slots)
* DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1, 13-May-88)
(clarify when initial value forms for defstruct options get evaled)
* EQUAL-STRUCTURE (Version 2, 8-Jun-88)
(What do EQUAL EQUALP and friends do on structures, vectors, etc.)
*** DRAFT: Multiple proposals ***
* EVAL-OTHER (Version 2, 8-Jun-88)
(Allow other data types to self-evaluate.)
* FUNCTION-CALL-EVALUATION-ORDER (Version 1, 22-Mar-88)
(when function cells are extracted isn't defined)
* HASH-TABLE-PRINTED-REPRESENTATION (Version 2, 8-Jun-88)
(make hash tables print as #H).
*** DRAFT ***
* LAST-N (version 2, 12-Mar-88)
(Extend LAST to take an optional N)
* MACRO-FUNCTION-ENVIRONMENT (Version 2, 8-Jun-88)
(Add environment argument to MACRO-FUNCTION)
* SHARPSIGN-PLUS-MINUS-NUMBER
(Allow #+68000, #-3600)
* SPECIAL-VARIABLE-TEST (Version 2, 21-May-88)
(Add SPECIAL-VARIABLE-P)
* STEP-ENVIRONMENT (Version 1)
(STEP isn't a macro, its a special form.)
* SUBSEQ-OUT-OF-BOUNDS (version 2, 29 Mar 88)
(it is an error to give out-of-bounds args to subseq)
* WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5, 7-Jun-88)
(interaction of WITH-OUTPUT-TO-STRING and FORMAT on adjustable arrays)
∂07-Jul-88 0732 X3J13-mailer DRAFT Minutes June meeting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 7 Jul 88 07:32:06 PDT
Date: 7 Jul 1988 10:29-EDT
Sender: MATHIS@A.ISI.EDU
Subject: DRAFT Minutes June meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 7-Jul-88 10:29:46.MATHIS>
DRAFT
Minutes of the X3J13 Meeting, Boston, June 15, 16 1988.
Wednesday, June 15
09:00 am Item 1, 2, 3, 4.
Item 1. 2a. Call to Order. Bob Mathis
Item 2. Introduction of attendees. Attendees list.
Future meetings. Bob recommended the Holiday Inn in Fairfax, VA for
October meeting which will be hosted by Contel.
Dick Gabriel described a planned Lisp conference for October
or November, 1989, in the Boston area. He also announced that, during
the conference, part of the Lisp museum will be on display.
Hawaii meeting will be Jan 17-20, 1989 (the week after POPL meets in
Austin, TX).
The Spring 1989 meeting will be held in the Palo Alto area.
Item 3. Approval of agenda.
Item 4. Approval of minutes. David Slater moved to table the approval
of the minutes until after JonL White and Larry Masinter's
comments were distributed.
9:30 am Item 5
Item 5 Editorial Subcommittee Report, Kathy Chapman.
Phase 1 document (1000p) will be ready for review in mid-July.
The document will be available for remote FTP access. Bob
Mathis emphasized that special document access needs should
be discussed with Bob or Kathy. The document is in TEX.
Phase 1 involves rewriting the CLTL into the format that
the X3J13 document will use. Review involves verifying the
correctness of the rewrite. The final document for Phase 4
is scheduled for June, 1989. Kathy is looking for volunteers
to suggest actual changes.
10:00 am Item 6
Character Subcommittee Report, Thom Linden
A proposal should be ready for voting on at the next meeting.
Bob Mathis noted that this topic was of great interest to many
different ISO committees and that this was the right time to
distribute our solution to the other committees.
10:05 am Item 7
Iteration Subcommittee Report, JonL White
Of the three proposals, Loop is ready for voting and OSS and
Generators need users. Guy Steele asked for a straw vote on
how many companies used some portion of Loops. Approximately
1/3 indicated that their companies did.
10:45 am Morning Break
11:10 am Item 7 (continued)
Dick Waters presented OSS, its description and status. The
files are available to FTP. Dick encouraged use and feedback.
The copyright on OSS belongs only to Dick, not to MIT. The
restriction on its use is that people will use it unchanged.
If changes are made, the name of the system should be changed.
Chris Perdue discussed the status of Generators. The
discussion focused on how complex proposals are to be included
in CL: ie., as kernel features, as features within a hierarchical
structure, or as optional features. No resolution occured.
12:30 pm Dick Waters raised some potential CL problems, and possible
solutions, in the area of prettyprinting, particularly.
12:35 pm Item 9, Lunch
01:45 pm Item 10
CLOS (88-002R, 88-003R), Gregor Kiczales
Gregor described the responses to comments on the last version of
CLOS, Chapters 1 and 2. Detailed questions were raised and
discussed.
03:00 pm Afternoon Break
03:15 pm Item 10 (continued)
Discussion continued on remaining issues to be resolved and
the form a resolution should make. Gregor moved and David
Moon seconded that:
The X3J13 Committee hereby votes to accept Chapters 1 and 2 of
the Common Lisp Object System, as defined in document 88-002R, for
inclusion in the Common Lisp language being specified by this
committee. Subsequent substative and wording changes will be
handled with the usual editorial and cleanup process.
Jim Antonio (who?) moved and JonL seconded an amendment to strike
the second sentence. The motion was defeated 9-12.
Dick Gabriel moved, and Larry Masinter seconded, to change the
motion to the following:
The X3J13 Committee hereby accepts chapters 1 and 2
of the Common Lisp Object System, as defined in document
88-002R, for inclusion in the Common Lisp language being
specified by this committee. Subsequent changes will be handled
through the usual editorial and cleanup processes.
The motion passed 22-0.
The original motion, as amended, passed 24-1.
Guy Steele stated the appreciation of himself and the committee
for the work of the CLOS subcommittee.
04:55 pm Ending remarks
Bob Mathis encouraged people to join relevant subcommittees. Larry
Masinter gave an overview to the Cleanup status that will be the
topic of the agenda tomorrow.
05:05 pm Item 11 Meeting adjourned
Thursday, June 16
09:10 am Item 12
Item 12 Call to Order. Bob Mathis
Attendance at the ISO meeting at Sunbird is limited to people
appointed by the committee. The present attendees are planned
to be Bob Mathis, Dick Gabriel, Kathy Chapman, Patrick Dussud,
and one person from the Scheme standardization effort.
David Bartley discussed IEEE Scheme Standardization meeting. Will
Clinger and someone else (who?) will be co-chairs.
Macro Subcommittee
Members of the subcommittee will be contacted by Bob Mathis to
find out status and intentions.
CLOS Subcommittee
Dick Gabriel announced that chapters 1 and 2 will be published
in SIGPLAN Notices and Lisp Journal and made available in such a
way as to allow republication by any vendor.
Error Subcommittee
Kent Pittman distributed a document describing what would
happen if an error were signalled. Gregor moved, and
Dick Gabriel seconded, that:
The X3J13 committee hereby accepts revision 18 of the Common
Lisp Condition System, as defined in document 88-005, for
inclusion in the Common Lisp language being specified by this
committee. Subsequent changes will be handled through the
usual editorial and cleanup processes. These changes will
include any necessary to reconcile the proposal with CLOS.
Bob Mathis called for a straw vote asking whether the second
sentence should be included in the motion. The straw vote
passed. Bob Mathis called for a straw vote asking whether
the third sentence should be included. The straw vote passed
13-11.
The motion was voted and passed unanimously. The committee
applauded Kent Pittman's work. Guy Steele moved, and JonL
White seconded, a vote of appreciation for Kent's efforts.
This motion also passed unanimously.
Compiler Cleanup Subcommittee
Sandra Loosemore discussed three proposals which had been
distributed yesterday. She encouraged comments to be sent
to the subcommittee by August 1st to:
CL-COMPILER@SAIL.STANFORD.EDU
Volunteers were asked to contact Sandra Loosemore or Steve
Haflich. Bob Mathis noted that the X3J13 committee was expecting
an overview of the issues and specific proposals to be
distributed in time to allow a vote at the October meeting.
Editorial Subcommittee
Kathy Chapman suggested that a member of each subcommittee
whose work is voted into CL should migrate first to the
Cleanup Subcommittee and then to the Editorial Subcommittee.
Kathy also suggested that each subcommittee should be
represented in the Editorial Subcommittee. There will be a
meeting of the Editorial Subcommittee during lunch.
10:40 am Morning Break
11:00 am Item 8
Item 8, Definition Specs Proposal, JonL White
JonL White repeated the Palo Alto proposal. The ensuing
discussion brought out the need for a written version of
the proposal that addresses implementation costs. It was
hoped that a written version would be available in advance
of the October meeting.
11:30 am Item 13
Item 13 Cleanup, Larry Masinter
Larry presented a status report showing that of the 21 issues
now under consideration, only three are still in "draft"
form. It is expected that a final vote will be taken in
October on currently known issues. The work after October
would then focus on ambiguities noted by the Editorial
Subcommittee and problems encountered with language areas
added to CL.
Larry Masinter moved, and JonL White seconded, that
FUNCTION-TYPE-REST-LIST-ELEMENT be added to the language.
Jeff moved, and Beckerly seconded, that the function
will be tabled until the next meeting. The motion to table
passed.
Larry Masinter moved, and JonL White seconded, that
FUNCTION-TYPE be added to the language.
12:30 pm Item 14 Lunch
01:20 pm Item 13 (continued)
Discussion centered on the automatic coercion of lambda
expressions. JonL White moved, and Gregor seconded, to
Change Section 2e
Clarify FUNCALL and APPLY and all CL functions that take
function arguments to also take a symbol, which will be
coerced to a function as with SYMBOL-FUNCTION.
Change Section 6b
(COERCE x 'FUNCTION), where the value of x is a list that
begins with LAMBDA, will return a FUNCTION similar to
(EVAL '(FUNCTION ,x)).
Mike Beckerley moved, and JonL seconded, to amend the amendment
to eliminate the word "clarify" from 2e and to replace
"similar to" with "as if by".
02:30 pm Afternoon break
02:40 pm Item 13 (continued)
David Moon moved, and David Slater seconded, to amend the
motion on the floor to
Add Section 2f:
FUNCALL and APPLY and all CL functions that take function
arguments also take a list whose car is LAMBDA, which will
be coerced to a function as if by
(EVAL '(FUNCTION ,x))
The amended motion failed 9-13.
A move to call off debate was called. The motion failed 8-12.
Steve Haflich moved, and Chris Perdue seconded to
Add Section 2f:
This is an incompatible change, in that FUNCALL, APPLY, and
all CL functions that take function arguments are not
required to take a list beginning with LAMBDA.
Barry Margolin moved, and Steve Haflich seconded, a friendly
amendment to Steve's amendment to
Add Section 2f:
This is an incompatible change in that it is an error to pass
anything other than a function or symbol as the function
The motion to amend the amendment passed 21-0.
The amendment to the cleanup proposal passed 20-1.
David Moon moved, and Barry Margolin seconded, to cut off
debate. The movement passed 17-4.
Jeff Dalton moved, and David Slater seconded, to table the
amended motion. The motion to table failed 6-13.
The chair announced that if 5 people believe the issue should
be sent to a mail ballot, it will be. No one challenged this
decision. Five people did not vote for a mail ballot.
The amended motion, FUNCTION-TYPE, passed 16-7.
Larry Masinter moved, and Guy Steele seconded, to add
SETF-FUNCTION-VS-MACRO to the language.
Following discussion and acquiring of a volunteer to help,
Larry Masinter moved to table the motion. The
tabling motion passed 15-6.
The discussion then moved on to the 18 new proposals.
Larry Masinter moved, and Sandra Loosemore seconded, to add
ADJUST-ARRAY-FILL-POINTER to the language. The motion passed
unanimously.
Larry Masinter moved, and xx seconded, to add
DATA-TYPES-HIERARCHY-UNDERSPECIFIED to the language.
Discussion noted that this is an incompatible change to
existing implementations, although the representatives of the
implementations felt this was a positive change.
Guy Steele moved, and Dan Pierson seconded, to change the
wording of the proposal as follows:
"explicitly forbid" to be replaced by "it is an error for"
The amendment passed unanimously.
The amended proposal passed unanimously.
Larry Masinter moved, and Dan Pierson seconded, to add
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME to the language. Discussion
on this was delayed.
Barry Margolin moved, and Steve Haflich seconded, to add
DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER to the language. The
motion passed unanimously.
The motion to add DEFSTRUCT-SLOTS-CONSTRAINTS-NAME was tabled
by general consent.
The discussion of DEFSTRUCT-DEFAULT-VALUE-EVALUATION led to
no resolution of opinion so it was decided not to bring the
proposal to a motion.
The discussion of EVAL-OTHER led to no resolution of opinion
so it was decided not to bring the proposal to a motion.
The discussion of FUNCTION-CALL-EVALUATION-ORDER led to no
resolution so it was decided not to bring the proposal to a
motion.
Dan Pierson moved,and Barry Margolin seconded, to add LAST,
with an argument, to the language. The motion passed 16-3.
Larry Masinter moved, and Dan Pierson seconded, to add
MACRO-FUNCTION-ENVIRONMENT to the language. The motion passed
unanimously.
Larry Masinter moved, and Barry Margolin seconded, to add
SHARPSIGN-PLUS-MINUS-NUMBEr to the language. The motion
moved was the proposal with the phrase "list of symbols and/or
numbers" changed to "list of symbols and/or integers".
The motion failed 7-10.
The discussion of SPECIAL-VARIABLE-TEST led to no resolution
of opinion so it was decided not to bring the proposal to a
motion.
The discussion of STEP-ENVIRONMENT led to no resolution of
opinion so it was decided not to bring the proposal to a
motion.
Larry Masinter moved, and Dan Pierson seconded, to add
SUBSEQ-OUT-OF-BOUNDS to the language. The motion passed
unanimously.
The discussion of WITH-OUTPUT-TO-STRING-APPEND-STYLE led to
no resolution of opinion so it was decided not to bring the
proposal to a motion.
Larry brought up a list of issues which are currently under
discussion.
05:05 pm Closing Comments
Jim Allard will talk to Bob Mathis about starting a working group on
delivery issues.
Dan Pierson offered to work with Barry Margolin on a position
paper on how implementations have to deal with the standard.
Bob Mathis emphasized that the October meeting would be a wrapup
of many technical issues. January will be a joint meeting with
ISO. The Palo Alto meeting will be a review of full document so
that at the following meeting we have the goal of having a document
which can be made public.
05:20 pm Item 16 Adjournment
Minutes submitted by Mary S. Van Deusen (June 16, 1988)
∂11-Aug-88 1444 X3J13-mailer CLOS workshop
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Aug 88 14:44:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 AUG 88 14:38:15 PDT
Date: Thu, 11 Aug 88 14:33 PDT
From: Gregor.pa@Xerox.COM
Subject: CLOS workshop
To: Common-Lisp@Sail.Stanford.edu, CommonLoops.pa@Xerox.COM,
X3J13@Sail.Stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
Message-ID: <19880811213330.2.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
This is the second announcement of the CLOS workshop to be held at PARC
October 3rd and 4th. This is a reminder to help us with our planning by
letting us know soon if you are planning to attend. My apologies to
people who receive multiple copies of this message.
To clarify the position paper requirement, the workshop is not limited
exclusively to those who have extensive experience writing CLOS code.
Anyone planning CLOS implementations, extensions, environments or CLOS
based application development is encouraged to attend. A position paper
can simply be a description of the kinds of issues you feel should the
CLOS community should address at the workshop.
Workshop for CLOS Users and Implementors
October 3rd and 4th
Xerox PARC
Palo Alto, California
We have been excited by the extent to which CLOS is already being
used, and the ways in which it is being extended. The purpose of
this workshop is to provide an opportunity for the members of the
CLOS community to get together and share their experience.
To provide a good start for the interchange, we are requesting that
participants supply a short position paper (1-3 pages) describing
work related to CLOS. Some topics of interest are:
Applications
Programming Techniques
Implementation
Programming Environment Tools
Extensions of CLOS
Techniques for Converting to CLOS
Meta Object Techniques and Theory
Critiques
We will try to support demonstrations or videotapes of applications,
programming environments, implementations or other relevant systems.
If you are planning to attend, please let us know by August 15th.
This will help us with planning and allow us to arrange a discount
rate at a local hotel.
Position papers should reach us by September 9th so that we can
organize a program and arrange for duplication of the papers.
Position papers, notice to attend, and other correspondence should
be sent to:
Gregor Kiczales
3333 Coyote Hill Rd.
Palo Alto, CA 94304
or by Internet mail to:
Gregor.pa@Xerox.com
-------
∂11-Aug-88 1607 X3J13-mailer CLOS workshop
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Aug 88 14:44:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 AUG 88 14:38:15 PDT
Date: Thu, 11 Aug 88 14:33 PDT
From: Gregor.pa@Xerox.COM
Subject: CLOS workshop
To: Common-Lisp@Sail.Stanford.edu, CommonLoops.pa@Xerox.COM,
X3J13@Sail.Stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
Message-ID: <19880811213330.2.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
This is the second announcement of the CLOS workshop to be held at PARC
October 3rd and 4th. This is a reminder to help us with our planning by
letting us know soon if you are planning to attend. My apologies to
people who receive multiple copies of this message.
To clarify the position paper requirement, the workshop is not limited
exclusively to those who have extensive experience writing CLOS code.
Anyone planning CLOS implementations, extensions, environments or CLOS
based application development is encouraged to attend. A position paper
can simply be a description of the kinds of issues you feel should the
CLOS community should address at the workshop.
Workshop for CLOS Users and Implementors
October 3rd and 4th
Xerox PARC
Palo Alto, California
We have been excited by the extent to which CLOS is already being
used, and the ways in which it is being extended. The purpose of
this workshop is to provide an opportunity for the members of the
CLOS community to get together and share their experience.
To provide a good start for the interchange, we are requesting that
participants supply a short position paper (1-3 pages) describing
work related to CLOS. Some topics of interest are:
Applications
Programming Techniques
Implementation
Programming Environment Tools
Extensions of CLOS
Techniques for Converting to CLOS
Meta Object Techniques and Theory
Critiques
We will try to support demonstrations or videotapes of applications,
programming environments, implementations or other relevant systems.
If you are planning to attend, please let us know by August 15th.
This will help us with planning and allow us to arrange a discount
rate at a local hotel.
Position papers should reach us by September 9th so that we can
organize a program and arrange for duplication of the papers.
Position papers, notice to attend, and other correspondence should
be sent to:
Gregor Kiczales
3333 Coyote Hill Rd.
Palo Alto, CA 94304
or by Internet mail to:
Gregor.pa@Xerox.com
-------
∂19-Aug-88 1210 X3J13-mailer Virginia and Hawaii X3J13 meetings
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Aug 88 12:10:21 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA04379g; Fri, 19 Aug 88 11:10:09 PST
Received: by challenger id AA12057g; Fri, 19 Aug 88 12:08:20 PDT
Date: Fri, 19 Aug 88 12:08:20 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8808191908.AA12057@challenger>
To: x3j13@sail.stanford.edu
Cc: jlz@lucid.com
Subject: Virginia and Hawaii X3J13 meetings
Date: 17 Aug 1988 21:02-EDT
Sender: MATHIS@A.ISI.EDU
The next meeting of X3J13 will be held October 10-13, 1988, in Fairfax,
Virginia, at the Contel Technology Center at 12015 Lee Jackson Highway (US
Route 50). Monday (October 10) will be used for subcommittee meetings and
Tuesday and Wednesday (October 11 and 12) will be used for the general
meeting. If necessary Thursday can also be used for subcommittee meetings.
The Contel Technology Center is located in the same building with Contel
Federal Systems across the parking lot from Fair Oaks Shopping Center. On the
other side of the shopping Center is the Holiday Inn Fair Oaks (11787 Lee
Jackson Highway, 703-352-2525) where some rooms are being held for our group.
These facilities are located at the intersection of US Route 50 and Interstate
66. This is outside the beltway two exits further west along I-66 from where
the Metro Orange line ends. Coming from National Airport, one would go by the
Pentagon along 110 through Rosslyn to go west on I-66. From Dulles airport,
take the first exit south onto Route 28 and then east on Route 50. The cab
fare from Dulles should be about $20 and from National about $30. There is
also bus service to Fair Oaks Shopping Center.
To register contact the hotel directly (and memtion Contel and this group) and
Jan Zubkoff at Lucid. The meeting fee will be $50 (make checks payable to
Lucid). For special local questions, contact Bob Mathis. We need an
indication, as soon as possible, about attendance and subcommittee meeting
needs.
The agenda of this meeting should be quite full. We expect final (or almost
final) reports from ALL subcommittees. The CLOS committee is working toward
presenting chapter 3. The clean-up committee will have a number of issues to
review. The editorial committee has the beginnings of a draft. The compiler,
character, and iteration committees should also have reports. Will there be
any others? From the subcommittee leaders, I need any documents they want
distributed, their subcommittee meeting plans, their expectations about full
X3J13 actions, and their anticipated time on the agenda.
The meeting after next will be held January 16-18, 1989, in Kauai, Hawaii. Jan
Zubkoff will be handling the arrangements and needs an indication of
anticipated attendance as soon as possible. We are not anticipating
subcommittee meetings there because we want to have final resolution of any
remaining issues, not just progress reports from the subcommittees. The
subcommittees may need to communicate between the Fairfax and Hawaii meetings.
For the January meeting agenda, it is anticipated that there will be a full
day on final clean-ups, a half day on final CLOS issues, a half day for other
yet-to-be-resolved issues from other sub-committees, and a full day on an
initial review of the draft of the standard.
*******************************************************************************
X3J13/ISO Meeting
X3J13: 1/16/89 - 1/18/89
ISO: 1/19/89 - 1/20/89
Kauai, Hawaii
Committee Meeting:
Dates: 1/16/89 - 1/18/89
Time: 9:00 - 5:00
City: Kapaa, Kauai, Hawaii
Place: Sheraton Coconut Beach Hotel
REGISTRATION FEE: $75 Payable to: LUCID, Inc.
ISO Meeting:
Dates: 1/19/89 - 1/20/89
Hotel Accomodations:
Hotel: Sheraton Coconut Beach Hotel
Address: Coconut Plantation
Phone: 808/822-3455
Directions from airport:
Turn right onto route 56 north (Kuhio Highway)
Look for the 7 mile marker and take next right (can see hotel from the
road but it is not on the main road)
Rate: $80/night
Mention: "X3J13 Standards Committee" for rate
Group Luau:
Place: Shearton Coconut Grove
Date: 1/17/89
Time: TBA
For further information contact:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
jlz@lucid.com
(415) 329-8400
!
X3J13/ISO January Meeting Registration Form
Please include check for $75.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
jlz@lucid.com
Name: _____________________________________________________________
Institution: ______________________________________________________
Net-Address: ______________________________________________________
Phone: ____________________________________________________________
Attend X3J13 _________ Attend ISO _________
Lunch 1/16: _________ yes _______ no
Lunch 1/17: _________ yes _______ no
Lunch 1/18: _________ yes _______ no
Luau 1/17 $38.50: _________ yes _______ no
∂04-Sep-88 1352 X3J13-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88 13:52:29 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 13:51:24 PDT
Date: 4 Sep 88 13:51 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
Subject: Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 2)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <880904-135124-8828@Xerox>
This is the final version as amended & subsequently passed.
>Guy Steele moved, and Dan Pierson seconded, to change the
>wording of the proposal as follows:
> "explicitly forbid" to be replaced by "it is an error for"
>The amendment passed unanimously.
>The amended proposal passed unanimously.
!
Issue: DATA-TYPES-HIERARCHY-UNDERSPECIFIED
References: CLtL 33-35 (data types)
CLtL 312 (DEFSTRUCT :INCLUDE option)
Category: CHANGE
Edit history: 24-Mar-88, version 1 by Steele
4-Sep-88, version 2 by X3J13 June 88
Problem description:
The types HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, and
RANDOM-STATE currently are not required to be disjoint from CONS, SYMBOL,
ARRAY, NUMBER, or CHARACTER. The same is true of DEFSTRUCT types. With
the arrival of CLOS, lack of disjointness will be inconvenient because one
cannot reliably use generic function dispatch on these types.
Proposal (DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT):
Remove the third and antepenultimate bulleted items from section 2.15 is
CLtL and replace with the following:
* The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, HASH-TABLE, READTABLE,
PACKAGE, PATHNAME, STREAM, RANDOM-STATE, and any single other type created
by DEFSTRUCT [or DEFCLASS] are pairwise disjoint.
Also, in the discussion of the DEFSTRUCT :INCLUDE option, it is an error for
the type given to the :INCLUDE option to be CONS, SYMBOL, ARRAY, NUMBER,
CHARACTER, HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, or
RANDOM-STATE.
Rationale:
It would be useful to extend sequence functions to operate on streams
or hash tables, for example, through the CLOS generic function mechanism.
This is not possible under the current specification.
Current practice:
Some implementations in effect use DEFSTRUCT to define data structures
such as hash tables and random-states.
Cost to Implementors:
Small or nonexistent. The main reason this disjointness was not specified
in CLtL was the possibility that structures might not be easily
distinguishable: a stupid concern over a slight efficiency. This
implementation freedom apparently has not been exploited in practice.
Cost to Users:
None.
Cost of non-adoption:
CLOS will be less useful.
Benefits:
CLOS will be more useful.
Esthetics:
This makes the type system simpler and easier to understand.
Discussion:
This suggestion originated in the CLOS committee.
----- End Forwarded Messages -----
∂04-Sep-88 1342 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88 13:42:31 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 13:39:41 PDT
Date: 4 Sep 88 13:39 PDT
From: Masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 12)
line-fold: NO
Message-ID: <880904-133941-8818@Xerox>
This is the final version of the FUNCTION-TYPE issue, as passed at the June 88 X3J13 meeting; that is, it incorporates the amendments that were adopted before the issue was adopted.
I hope to be getting issues out to the X3J13 list as the cleanup committee comes to some final agreement on them, over the next two weeks.
!
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
19-May-88, Version 10 by Masinter, (modify as per X3J13)
24-May-88, Version 11 by van Roggen
(don't coerce lists, relax SYMBOL-FUNCTION reqs)
4-Sep-88, Version 12 by Masinter
(incorporate amendments adopted at June 88 X3J13)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
Proposal FUNCTION-TYPE:X3J13-MARCH-88
This proposal is basically the STRICT-REDEFINITION proposal of version 9
of this issue, correcting a few typos, changing section 2E as
agreed upon at X3J13 March 1988, allowing symbols but not lists to
be FUNCALLed or APPLYed, and relaxing some SYMBOL-FUNCTION/FBOUNDP
requirements.
1. Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint. In particular, a list may not be used
to implement any FUNCTION subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
2. Define that a ``function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.
2a. This type no longer includes objects of type SYMBOL or lists
whose CAR is LAMBDA.
2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible
change.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. FUNCALL and APPLY and all Common Lisp functions that
take function arguments to also take a symbol, which will
be coerced to a function as if by SYMBOL-FUNCTION.
2f. This is an incompatible change in that it is an error to pass
anything other than a function or symbol as the functional
argument.
3. Clarify that the result of a FUNCTION special form must be a function.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that FBOUNDP must return true for a symbol naming a macro or
a special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. SETF of SYMBOL-FUNCTION requires a FUNCTION as the new value.
It is an error to set the SYMBOL-FUNCTION of a symbol to a
symbol or a list or the value returned by SYMBOL-FUNCTION on
the name of a macro or a special form.
5c. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
6. COERCE is extended to allow objects to be coerced to type FUNCTION.
6a. (COERCE symbol 'FUNCTION) extracts the SYMBOL-FUNCTION of the
given symbol, signalling an error if the symbol is not FBOUNDP or
if the symbol names a macro or a special-form.
6b. (COERCE x 'FUNCTION), where the value of x is a list that
begins with LAMBDA, will return a FUNCTION similar to
(EVAL '(FUNCTION ,x)).
7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the expansion interface hook by
MACROEXPAND-1.
Rationale:
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
This proposal is a compromise between a CONSERVATIVE proposal (which left
FUNCTION alone and introduced a new type), and a STRICT-REDEFINITION proposal,
which incompatibly changed not only the FUNCTION type and SYMBOL-FUNCTION,
but also the behavior of FUNCALL, APPLY and functions with functional
arguments.
For compatibility reasons symbols are still acceptable to FUNCALL et al.,
but for aesthetic reasons lambda-expressions (lists whose CAR is LAMBDA
and whose CADR is a list) are no longer acceptable.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is true for values
returned by FUNCTION, symbols that are FBOUNDP, and lambda expressions.
In some implementations, (TYPEP x 'FUNCTION) is true only for values
returned by FUNCTION.
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations have exactly the
semantics described in this proposal.
Cost to Implementors:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations.
Compiled functions are true functions in almost all current
implementations, but in many implementations, interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, this representation would have to be different
(implemented either as structures or as some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).
Cost to Users:
The changes to FUNCTIONP and the FUNCTION type declaration are relatively easy
to deal with.
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell, or expected lists back, will
have to change. Such code was already not portable, however, since some
implementations signal an error when this is done.
The original STRICT-REDEFINITION proposal required users to deal with
the use of symbols and lambda-expressions as functional arguments. However
this proposal is compatible with current CLtL definition in the use of
symbols, which would be the hardest change to make. There are probably
relatively few uses of lambda-expressions as ``functions'', which can
be dealt with by (EVAL `(FUNCTION ,lambda-expresssion)).
Benefits:
The term ``function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.
The type hierarchy would be simplified.
This proposal brings Common Lisp slightly closer to Scheme and the
work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with the FUNCTION type.
Aesthetics:
This proposal improves the aesthetics of the language.
Lambda-expressions do not obey the normal, apparent scoping rules because
free variables cannot refer to lexical bindings. This is because
coercing a list to a function would mean (EVAL `(FUNCTION ,list)).
The following code does -not- count the number of nodes in a graph:
(LET ((COUNTER 0))
(TRAVERSE-THING '(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
since it is not the same as
(LET ((COUNTER 0))
(TRAVERSE-THING #'(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
which does pass around a closure incrementing the LET variable.
(These examples assume COUNTER wasn't PROCLAIMed SPECIAL.)
Making the coercion of lambda-expressions to functions explicit with
the use of EVAL will encourage less confusing code and also highlight
that use of EVAL.
Discussion:
This issue has been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Many different alternatives have been discussed both in the cleanup committee
and X3J13. Two proposals were circulated at the March 1988 meeting of X3J13;
this version is the result of discussions at that meeting. It is a compromise
between the conflicting goals of backward compatibility, flexibility in the
language, and simple semantics.
This proposal does not address the issue of when coercion to functions occur.
For example, it is allowed to write
(MAPCAR 'FROB my-list)
It is not specified when the coercion of FROB to its SYMBOL-FUNCTION
occurs. For example,
(DEFUN FROB (X)
(WHEN (> X 0) (SETF (SYMBOL-FUNCTION 'FROB) #'(LAMBDA (X) NIL)))
T)
(MAPCAR 'FROB '(-1 -1 1 1))
may return different results if MAPCAR coerces its functional argument
once rather than for each element. This may require a separate
cleanup issue.
∂08-Sep-88 1751 X3J13-mailer Fairfax X3 registration form
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Sep 88 17:51:20 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00481g; Thu, 8 Sep 88 16:50:15 PST
Received: by challenger id AA05802g; Thu, 8 Sep 88 17:48:06 PDT
Date: Thu, 8 Sep 88 17:48:06 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809090048.AA05802@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax X3 registration form
I've had a few people ask about the dates of the next meeting... The dates in
the last message were correct. It was decided to have only 1 day of
subcommittee meetings before the committee meeting in October. I have
included the last message pertaining the the Fairfax meeting and a
registration form. See you there! ---jan---
The next meeting of X3J13 will be held October 10-13, 1988, in Fairfax,
Virginia, at the Contel Technology Center at 12015 Lee Jackson Highway (US
Route 50). Monday (October 10) will be used for subcommittee meetings and
Tuesday and Wednesday (October 11 and 12) will be used for the general
meeting. If necessary, Thursday can also be used for subcommittee meetings.
The Contel Technology Center is located in the same building with Contel
Federal Systems across the parking lot from Fair Oaks Shopping Center. On the
other side of the shopping Center is the Holiday Inn Fair Oaks (11787 Lee
Jackson Highway, 703-352-2525) where some rooms are being held for our group.
These facilities are located at the intersection of US Route 50 and Interstate
66. This is outside the beltway two exits further west along I-66 from where
the Metro Orange line ends. Coming from National Airport, one would go by the
Pentagon along 110 through Rosslyn to go west on I-66. From Dulles airport,
take the first exit south onto Route 28 and then east on Route 50. The cab
fare from Dulles should be about $20 and from National about $30. There is
also bus service to Fair Oaks Shopping Center.
To register contact the hotel directly (and mention Contel and this group) and
Jan Zubkoff at Lucid. The meeting fee will be $50 (make checks payable to
Lucid). For special local questions, contact Bob Mathis. We need an
indication, as soon as possible, about attendance and subcommittee meeting
needs.
The agenda of this meeting should be quite full. We expect final (or almost
final) reports from ALL subcommittees. The CLOS committee is working toward
presenting chapter 3. The clean-up committee will have a number of issues to
review. The editorial committee has the beginnings of a draft. The compiler,
character, and iteration committees should also have reports. Will there be
any others? From the subcommittee leaders, I need any documents they want
distributed, their subcommittee meeting plans, their expectations about full
X3J13 actions, and their anticipated time on the agenda.
!
X3J13 October Meeting Registration Form
Please include a check for $50.00 payable to `LUCID' mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
jlz@lucid.com
Name: _____________________________________________________________
Institution: ______________________________________________________
Net-Address: ______________________________________________________
Phone: ____________________________________________________________
Attend X3J13 _________
Lunch 10/11: _________ yes _______ no
Lunch 10/12: _________ yes _______ no
∂12-Sep-88 0841 X3J13-mailer Availability of the standard
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 08:41:27 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA25711; Mon, 12 Sep 88 08:40:11 PDT
Message-Id: <8809121540.AA25711@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 11:33
To: x3j13@sail.stanford.edu
Subject: Availability of the standard
For you information:
A copy of the phase 1 standard (CLtL only) is available on
hudson.dec.com, username: ftp_user, password: ftppleasework.
This copy is VERY preliminary. Please do not spend time reviewing
this information because it will change shortly.
At the completion of phase 2, comments from the X3J13 committee
will be accepted. At this time, only comments from the editorial
committee are being processed.
kathy chapman
∂12-Sep-88 1344 X3J13-mailer Common Lisp Mailing Lists
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I intend to stop maintaining the various Common Lisp mailing lists
(including X3J13) by the end of this year. I would like someone else to
take over my duties (which I have performed since 1981). Because the SAIL
computer will be de-commissioned within 1 year from now, the lists will
need to move anyway.
-rpg-
∂12-Sep-88 1954 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 19:54:09 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00892g; Mon, 12 Sep 88 18:52:49 PST
Received: by bhopal id AA02266g; Mon, 12 Sep 88 19:52:12 PDT
Date: Mon, 12 Sep 88 19:52:12 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809130252.AA02266@bhopal>
To: Masinter.pa@Xerox.COM
Cc: X3J13@Sail.stanford.edu, Masinter.pa@Xerox.COM
In-Reply-To: Masinter.pa@Xerox.COM's message of 4 Sep 88 13:39 PDT <880904-133941-8818@Xerox>
Subject: Issue: FUNCTION-TYPE (version 12)
There are several gaffs in this version, and I don't remember the previous
versions well enough to know if they are recently introduced or have been
around since the beginning. In fact, until the June 1988 X3J13 meeting, the
whole issue was divided enough (because of the coercion issue) that minor
gaffs like those pointed out below were not worth bothering about.
re: 5c. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
Surely the distinction between FUNCTION and SYMBOL-FUNCTION is the access
to lexical redefinitions, versus access restricterd to the global database
(the symbol-function attributes of all symbols). I *** would not *** try
to discourage use of, nor disparage, the SYMBOL-FUNCTION function. Further-
more, this isn't the time nor the place to debate the issue of how symbols
are implemented -- *must* they really be implemented as little structures,
or could their "attributes" be done other ways? There is no need to relegate
SYMBOL-FUNCTION to a set of "accessors on symbols", nor to bring up that
red-herring at all.
re: 6a. (COERCE symbol 'FUNCTION) extracts the SYMBOL-FUNCTION of the
given symbol, signalling an error if the symbol is not FBOUNDP or
if the symbol names a macro or a special-form.
"Extracts" seems a bit rude here; other documentary places probably would
just have said "returns the symbol-function of the given symbol", assuming
that the notion of a symbol having a 'symbol-function' attribute is already
well understood. A very similar issue is the accessing of the global value
of a variable -- one would talk about the symbol-value of the variable.
re: 6b. (COERCE x 'FUNCTION), where the value of x is a list that
begins with LAMBDA, will return a FUNCTION similar to
(EVAL '(FUNCTION ,x)).
It's surely bassackwards to describe what COERCE does by having to resort
to what EVAL does. Why not, for example, describe it in terms of what
(FUNCTION <x>) *** compiles into ***? On the contrary -- rather than
depending on an uncertain definition of either EVAL or COMPIL -- wouldn't
it be much cleaner (and clearer) to let FUNCTION be "primary", and then
document this case of COERCE in terms of what FUNCTION does. E.g.:
6b. (COERCE x 'FUNCTION), where the value of x is a list of form
(LAMBDA ...), will return a closure that is the functional
interpretation of x in the null lexical environment (see
CLtL, p87). If x is a list not of this form, an error
is signalled. [Note: a closure is always a function.]
This leaves out the issue of whether it's EVAL's action, or COMPILE's action,
that is the defining term. Unless these "actions" are sidestepped, then
it would be impossible to define this function unless EVAL were sufficiently
elaborated in the standard [e.g., such as Henry Lieberman's Common EVAL
proposal would do].
Under "Aesthetics:", the discussion is again not easy to follow.
re: Lambda-expressions do not obey the normal, apparent scoping rules because
free variables cannot refer to lexical bindings. This is because
coercing a list to a function would mean (EVAL `(FUNCTION ,list)).
I honestly don't know what this is trying to say. If it is trying to
highlight the difference between the interpretations of:
(QUOTE (LAMBDA ...))
and
(FUNCTION (LAMBDA ...))
then I certainly didn't get that from reading this paragraph [but rather
from a belief that this issue should be explicitly stated somewhere in the
proposal].
re: Making the coercion of lambda-expressions to functions explicit with
the use of EVAL will encourage less confusing code and also highlight
that use of EVAL.
Again, isn't this completely backwards? The whole point of this cleanup
issue to to *** stop *** programmers from writing "quotified" lambda
expressions, and to strongly encourage them to use "real" functions
instead. I'm sure we don't need to encourage the use of EVAL!
-- JonL --
∂13-Sep-88 0841 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Sep 88 08:41:23 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 13 Sep 88 11:38:00 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 13 Sep 88 11:39:06 EDT
Date: Tue, 13 Sep 88 11:39 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: FUNCTION-TYPE (version 12)
To: Jon L White <jonl@lucid.com>
Cc: Masinter.pa@xerox.com, X3J13@sail.stanford.edu
In-Reply-To: <8809130252.AA02266@bhopal>
Message-Id: <19880913153928.7.BARMAR@OCCAM.THINK.COM>
Date: Mon, 12 Sep 88 19:52:12 PDT
From: Jon L White <jonl@lucid.com>
Further-
more, this isn't the time nor the place to debate the issue of how symbols
are implemented -- *must* they really be implemented as little structures,
or could their "attributes" be done other ways? There is no need to relegate
SYMBOL-FUNCTION to a set of "accessors on symbols", nor to bring up that
red-herring at all.
Whether symbols are actually implemented as structures, they are
conceptually structures with several slots.
re: 6b. (COERCE x 'FUNCTION), where the value of x is a list that
begins with LAMBDA, will return a FUNCTION similar to
(EVAL '(FUNCTION ,x)).
It's surely bassackwards to describe what COERCE does by having to resort
to what EVAL does. Why not, for example, describe it in terms of what
(FUNCTION <x>) *** compiles into ***? On the contrary -- rather than
depending on an uncertain definition of either EVAL or COMPIL -- wouldn't
it be much cleaner (and clearer) to let FUNCTION be "primary", and then
document this case of COERCE in terms of what FUNCTION does. E.g.:
6b. (COERCE x 'FUNCTION), where the value of x is a list of form
(LAMBDA ...), will return a closure that is the functional
interpretation of x in the null lexical environment (see
CLtL, p87). If x is a list not of this form, an error
is signalled. [Note: a closure is always a function.]
This leaves out the issue of whether it's EVAL's action, or COMPILE's action,
that is the defining term. Unless these "actions" are sidestepped, then
it would be impossible to define this function unless EVAL were sufficiently
elaborated in the standard [e.g., such as Henry Lieberman's Common EVAL
proposal would do].
We debated long and hard at the last meeting to get the wording of this
particular clause, although I think it was mostly over the phrase that
finally turned into "similar to" (I think I originally wrote "equivalent
to", but people weren't sure what kind of equivalence it implied).
First of all, not all implementations will bother creating a closure for
a function that is in the null lexical environment (Symbolics doesn't),
so it would be wrong to specify that it returns a closure.
The reason this particular form was used as the definition is that the
justification given in the previous versions of the proposal, which
lacked this explicit coercion mechanism, was that this conversion could
be done by calling (EVAL '(FUNCTION x)). Therefore, we decided to
codify that particular idiom.
Since most uses of (COERCE <lambda-exp> 'FUNCTION) will not have a
constant <lambda-exp> (because then #'<thing> could have been used), I
think it is pretty unlikely to be compiled, although there is nothing
preventing it. By the same token, there's nothing preventing (EVAL
`(FUNCTION ,<lambda-exp>)) from compiling the function, either. They
really are equivalent at the language level.
barmar
∂13-Sep-88 1139 X3J13-mailer Re: Issue: FUNCTION-TYPE (version 12)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Sep 88 11:39:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 SEP 88 11:29:28 PDT
From: masinter.PA@Xerox.COM
Date: 13 Sep 88 11:27:26 PDT
Subject: Re: Issue: FUNCTION-TYPE (version 12)
In-reply-to: barmar@Think.COM's message of Tue, 13 Sep 88 11:39 EDT,
<19880913153928.7.BARMAR@OCCAM.THINK.COM>
To: Barry Margolin <barmar@Think.COM>
cc: Jon L White <jonl@lucid.COM>, Masinter.PA@Xerox.COM, X3J13@sail.stanford.edu
Message-ID: <880913-112928-3452@Xerox>
I'd just as soon lay this to rest. The cleanup issue writeups are intended
primarily for ourselves -- that we understand what we're voting on. The
proposals are intended for the editor and the editorial committee -- that they
understand the language they are describing. Certainly I would expect that the
language we use to describe how CLtL should change is not the same as the
language used to describe the language once changed.
If you have some suggestions for wording and terminology in the standard (and I
think the issues you both raise are valid), you should take them up with the
editor and the editorial committee (cl-editorial@sail.stanford.edu) and not the
committee of the whole.
Thanks,
Larry
∂15-Sep-88 0225 X3J13-mailer "passed" cleanup issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88 02:25:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 88 01:35:24 PDT
Date: 15 Sep 88 01:35 PDT
From: masinter.pa@Xerox.COM
Subject: "passed" cleanup issues
To: x3J13@sail.stanford.edu
reply-to: Masinter.pa@Xerox.COM
Message-ID: <880915-013524-2103@Xerox>
The cleanup issues passed at previous meetings of X3J13 are now available for
anonymous FTP from host arisia.xerox.com (address 13.1.100.206). The files are
plain text, although some of the files may be missing line-breaks. If you do not
have network access, I can mail you copies of any issue.
I will be making text of the pending issues available in the same way.
user anonymous, any password will do.
The passed issues on the directory clcleanup/passed.
I will be making the text of pending issues available in the same way, in the
directory clcleanup/pending.
ftp arisia.xerox.com
Connected to arisia.
220 arisia FTP server (Version 4.15 Sat Nov 7 15:24:41 PST 1987) ready.
Name (arisia.xerox.com:masinter): anonymous
331 Guest login ok, send ident as password.
Password:
230 Guest login ok, access restrictions apply.
ftp> cd clcleanup/passed
ftp> ls
200 PORT command okay.
150 Opening data connection for /bin/ls (13.1.100.218,1029) (0 bytes).
adjust-array-displacement
adjust-array-fill-pointer
append-dotted
aref-1d
assoc-rassoc-if-key
colon-number
compiler-warning-stream
data-types-hierarchy-underspecified
declare-macros
defstruct-slots-constraints-number
defvar-documentation
defvar-init-time
defvar-initialization
disassemble-side-effect
do-symbols-duplicates
dribble-technique
flet-declarations
flet-implicit-block
format-atsign-colon
format-colon-uparrow-scope
format-comma-interval
format-op-c
function-type
function-type-key-name
get-setf-method-environment
import-setf-symbol-package
keyword-argument-name-package
last-n
macro-function-environment
princ-character
push-evaluation-order
reduce-argument-extraction
shadow-already-present
sharpsign-plus-minus-package
226 Transfer complete.
767 bytes received in 2.3 seconds (.32 Kbytes/s)
∂15-Sep-88 1617 X3J13-mailer additional passed clean-up issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88 16:17:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 88 15:42:33 PDT
Date: 15 Sep 88 15:42 PDT
From: masinter.pa@Xerox.COM
To: X3J13@Sail.stanford.edu
Subject: additional passed clean-up issues
reply-to: Masinter.pa@Xerox.COM
Message-ID: <880915-154233-3261@Xerox>
It was pointed out that I missed some passed issues:
PATHNAME-STREAM
PATHNAME-SYMBOL
I can't find a record of this issue being voted on:
SUBSEQ-OUT-OF-BOUNDS
It was distributed before the June 1988 meeting. I will include it in the set of
pending issues unless someone has a record of it being accepted already.
∂16-Sep-88 1145 X3J13-mailer agenda items please
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Sep 88 11:45:09 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02073g; Fri, 16 Sep 88 10:43:32 PST
Received: by challenger id AA04779g; Fri, 16 Sep 88 11:41:19 PDT
Date: Fri, 16 Sep 88 11:41:19 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809161841.AA04779@challenger>
To: x3j13@sail.stanford.edu
Subject: agenda items please
If you have anything you wish to bring to a vote, please remember committee
member need to RECEIVE proposals 2 weeks before the meeting. (Mail early next
week.) Call Bob Mathis for mailing labels 703/359-0203.
Below is a rough draft of the agenda. Please let me know ASAP if you have
anything to add. See you soon!
---jan---
**************DRAFT**************
X3J13 Committee Meeting Agenda
October 11 - 12, 1988
1 Call to Order, October 11, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Character Subcommittee Report and Vote, Thom Linden (3 hrs)
6 Lunch, 12:00pm - 1:00pm
7 CLOS Workshop Report, Gregor Kiczales
8 Compiler Subcommittee Report and Vote, Sandra Loosemore (1.5 hrs)
9 Editorial Subcommittee Report, Kathy Chapman (30 minutes)
10 ??
11 Recess, 5:00pm
12 Call to Order, October 12, 9:00am
13 Clean-up, Larry Masinter
14 Lunch, 12:00pm - 1:00pm
15 Other committee reports
16 Adjournment, 5:00pm
Next X3J13 meeting: 1/16 - 1/18 1989 Kauai, Hawaii
∂16-Sep-88 1157 X3J13-mailer subcommittee meetings
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Sep 88 11:57:10 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02080g; Fri, 16 Sep 88 10:55:43 PST
Received: by challenger id AA04785g; Fri, 16 Sep 88 11:53:30 PDT
Date: Fri, 16 Sep 88 11:53:30 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809161853.AA04785@challenger>
To: x3j13@sail.stanford.edu
Subject: subcommittee meetings
As you can see there is some overlap. Any other subcommittee meetings should
be scheduled on Sunday or Monday evening. Please let me know of any changes
or additions.
Subcommittee meetings
October 10, 1988
9:30 - 5:00 Characters (4-5)
9:30 - 12:30 Cleanup (?)
11:30 - 3:30 Editorial (?)
2:00 - 5:00 Compiler (?)
∂19-Sep-88 1857 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Sep 88 18:57:18 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03895g; Mon, 19 Sep 88 17:55:36 PST
Received: by bhopal id AA15915g; Mon, 19 Sep 88 18:55:04 PDT
Date: Mon, 19 Sep 88 18:55:04 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809200155.AA15915@bhopal>
To: barmar@Think.COM
Cc: Masinter.pa@xerox.com, X3J13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 13 Sep 88 11:39 EDT <19880913153928.7.BARMAR@OCCAM.THINK.COM>
Subject: Issue: FUNCTION-TYPE (version 12)
re: First of all, not all implementations will bother creating a closure for
a function that is in the null lexical environment (Symbolics doesn't),
so it would be wrong to specify that it returns a closure.
See CLtL, p87: "If fn is a lambda-expression, then a ``lexical closure''
is returned, that is a function that when invoked will execute the body
of the lambda-expresssion in such a way as to observe the rules of
lexical scoping properly." This applies regardless of whether or not
the lexical environment is null.
What many persons miss is the fact that a perfectly ordinary compiled
function with a null lexical environment satisfies the definition of
"closure". Possibly they are misled, as you may have been, by the
fact that some vendors have a lower-level data-type that distinguishes
functions closed over the null lexical environment from those closed
over something more significant.
Incidentally, I thought this was a "Cleanup" subcommittee issue, and only
now notice that is beng cc'd to X3J13 as a whole. Was this a mistake?
-- JonL --
∂23-Sep-88 1056 X3J13-mailer issue COMPILE-FILE-PACKAGE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:56:00 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28982; Fri, 23 Sep 88 11:54:35 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02517; Fri, 23 Sep 88 11:54:31 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231754.AA02517@defun.utah.edu>
Date: Fri, 23 Sep 88 11:54:30 MDT
Subject: issue COMPILE-FILE-PACKAGE
To: x3j13@sail.stanford.edu
Issue: COMPILE-FILE-PACKAGE
References: CLtL p. 182, 183
Category: CHANGE, CLARIFICATION
Edit History: 1 Sep 1988, Sandra Loosemore (initial version)
21 Sep 1988, Sandra Loosemore (minor tweak to current practice)
Problem Description:
The variable *PACKAGE* is rebound by the function LOAD, so that its
old value will be restored in spite of any calls to IN-PACKAGE
appearing in the file being loaded. Since COMPILE-FILE must evaluate
any top-level calls to IN-PACKAGE that it sees, it may also alter the
value of *PACKAGE*. It is inconsistent to have COMPILE-FILE and LOAD
behave differently regarding the rebinding of this variable.
Proposal COMPILE-FILE-PACKAGE:REBIND:
Require COMPILE-FILE to rebind *PACKAGE* before processing the file.
Rationale:
This makes COMPILE-FILE and LOAD more consistent. It is a more
compatible solution than either requiring LOAD not to rebind
*PACKAGE*, or removing the specialness of IN-PACKAGE and the other
package functions.
Current Practice:
Lucid Common Lisp, the TI Explorer, and VaxLisp already implement this
proposal.
Cost to implementors:
Trivial.
Cost to users:
I find it hard to believe that users would consider COMPILE-FILE altering
the value of *PACKAGE* as a useful side effect.
Benefits:
The language is made more uniform.
Discussion:
-------
∂23-Sep-88 1053 X3J13-mailer compiler cleanup issue status
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:53:25 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28898; Fri, 23 Sep 88 11:52:03 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02492; Fri, 23 Sep 88 11:52:00 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231752.AA02492@defun.utah.edu>
Date: Fri, 23 Sep 88 11:51:59 MDT
Subject: compiler cleanup issue status
To: x3j13@sail.stanford.edu
X3J13 Compiler Cleanup Status as of 23 Sep 1988:
================================================
Old issues (distributed for comments at the June meeting), ready to be
voted upon:
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
What are the compile-time side-effects of the various defining
macros?
EVAL-WHEN-NON-TOP-LEVEL
What does EVAL-WHEN mean when it does not appear as a top-level
form?
DEFINING-MACROS-NON-TOP-LEVEL
Can defining macros such as DEFUN appear in non-top-level
locations?
This issue provoked the only comments that were received since
the last meeting:
* The wording of section 4 was garbled.
This has been fixed in the latest version of the proposal.
* Many implementations do not allow a lexical environment to be
shared between compiled and interpreted functions.
A new issue, COMPILE-ARGUMENT-PROBLEMS, has been written up
to deal with this problem.
* Forms within a COMPILER-LET and the expansion of a top-level
macro should also be considered top-level.
This has been fixed.
New issues that are ready to be voted upon:
COMPILE-ARGUMENT-PROBLEMS
What functions can be compiled with COMPILE?
COMPILE-FILE-PACKAGE
COMPILE-FILE should rebind *PACKAGE*.
OPTIMIZE-DEBUG-INFO
What OPTIMIZE quality controls debuggability of compiled code?
PROCLAIM-INLINE-WHERE
INLINE proclamations should be placed before the corresponding
DEFUN.
Issues in draft form (comments requested):
COMPILE-ENVIRONMENT-CONSISTENCY
What things can the compiler safely "wire in" to code being
compiled?
PROCLAIM-ETC-IN-COMPILE-FILE
Add PROCLAIM, REQUIRE to list of N random package functions that
COMPILE-FILE must eval at compile time.
Issues in progress (no proposals ready yet):
LOAD-TIME-EVAL
What does #, mean? Where can it appear?
COMPILED-CONSTANTS
Are quoted constants in compiled code read-only? Must the compiler
handle circular constants? Preserve nonprintable aspects of constant
data?
-------
∂23-Sep-88 1056 X3J13-mailer issue OPTIMIZE-DEBUG-INFO
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:56:32 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28993; Fri, 23 Sep 88 11:55:10 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02522; Fri, 23 Sep 88 11:55:07 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231755.AA02522@defun.utah.edu>
Date: Fri, 23 Sep 88 11:55:06 MDT
Subject: issue OPTIMIZE-DEBUG-INFO
To: x3j13@sail.stanford.edu
Issue: OPTIMIZE-DEBUG-INFO
References: CLtL p. 160
Category: ADDITION
Edit History: V1 9 Sep 1988, David Gray (initial version)
V2 19 Sep 1988, David Gray (delete first alternative)
Problem Description:
The OPTIMIZE declaration provides a way to tell the compiler how important
various qualities are in order to guide which optimizations are done.
There is another quality, however, that is not mentioned, but is an
important consideration for the compiler: how much information
should be included in the object code to facilitate debugging. This
includes both annotation added to enable a debugger to display more
information to the user, and also suppression of optimizations that would
confuse debugging by making it harder to connect the object code with the
source code.
Proposal OPTIMIZE-DEBUG-INFO:NEW-QUALITY:
In the description of the OPTIMIZE declaration, add an additional quality
named DEBUG, described as "ease of debugging".
Rationale:
Since ease of debugging is an issue that the user will be concerned with,
and is an issue that the compiler needs to consider, this provides a clear
way for the user to control the amount of debugging information placed in
the object module, with DEBUG=0 meaning none and DEBUG=3 meaning "as much
as possible".
Current Practice:
No current implementation of this is known.
Cost to implementors:
All would have to update their handling of OPTIMIZE declarations to accept
the new quality.
Cost to users:
One more little feature to learn. Some problems may result from the
addition of the symbol DEBUG to the LISP package.
Benefits:
Provides users a standard way to control the interaction between
the compiler and debugger, and saves implementors from having to invent
implementation-dependent solutions.
Costs of Non-Adoption:
Continued confusion about how debug information should be controlled.
Discussion:
Concern has been raised that there is already a problem with the
non-orthogonality of SPEED, SAFETY, and SPACE that would be made even
worse with DEBUG added, since users tend to be perplexed by the
interactions of these qualities.
-------
∂23-Sep-88 1057 X3J13-mailer issue PROCLAIM-INLINE-WHERE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:57:11 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA29014; Fri, 23 Sep 88 11:55:45 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02527; Fri, 23 Sep 88 11:55:42 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231755.AA02527@defun.utah.edu>
Date: Fri, 23 Sep 88 11:55:41 MDT
Subject: issue PROCLAIM-INLINE-WHERE
To: x3j13@sail.stanford.edu
Issue: PROCLAIM-INLINE-WHERE
References: CLtL p. 156, 159
Category: CLARIFICATION
Edit History: 16 Sept. 88 V1 by David Gray
Problem Description:
CLtL does not specify whether a (PROCLAIM '(INLINE ...)) should come
before or after the DEFUNs that it refers to, but in most
implementations the compiler can't expand a function inline
unless it knows at the time it processes the DEFUN that the definition
needs to be saved for use in inline expansion.
Proposal PROCLAIM-INLINE-WHERE:BEFORE:
Clarify that (PROCLAIM '(INLINE ...)) tells the compiler both that it is
desirable to use inline expansion for calls to the functions indicated
and that the compilation of any subsequent DEFUN of one of the functions
should record whatever information is used for performing inline
expansions. Consequently, the proclamation should precede the
definition of the functions that it names. When compiling a function
call, if the function has been proclaimed INLINE but the current
definition of the function was established before the PROCLAIM was
processed, it is implementation-dependent whether the function will
actually be expanded inline.
Rationale:
This clarification brings the specification in line with current
practice. The only alternative would appear to be to require the
compiler to always save the definition of every function, and that
doesn't seem reasonable.
Test Cases/Examples:
Given the following input to COMPILE-FILE, does F1 get expanded inline
in F2?
(defun f1 (a) (+ a 100))
(proclaim '(inline f1))
(defun f2 (b) (f1 b))
Current Practice:
The documentation for Lucid and the TI Explorer both say that INLINE
proclamations need to precede the function definition. Symbolics
doesn't appear to document this, but requires it anyway. Thus none of
these three implementations do the inline expansion in the example
above.
Cost to implementors:
Probably none required, although given this clarification it would be
nice if compilers warned about an INLINE proclamation that follows the
indicated DEFUN in the same file.
Cost to users:
None.
Benefits:
Users will know how to use INLINE proclamations correctly.
Costs of Non-Adoption:
Continued confusion over cases such as the example above, which
conform to CLtL but don't do what is expected.
Discussion:
-------
∂23-Sep-88 1055 X3J13-mailer issue COMPILE-ARGUMENT-PROBLEMS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:55:37 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28972; Fri, 23 Sep 88 11:54:12 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02512; Fri, 23 Sep 88 11:54:08 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231754.AA02512@defun.utah.edu>
Date: Fri, 23 Sep 88 11:54:07 MDT
Subject: issue COMPILE-ARGUMENT-PROBLEMS
To: x3j13@sail.stanford.edu
Issue: COMPILE-ARGUMENT-PROBLEMS
References: CLtL p. 438-439
Issue FUNCTION-TYPE
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION, CHANGE
Edit History: V1, Sandra Loosemore (8 Aug 1988)
V2, Sandra Loosemore (21 Sep 1988)
Problem Description:
The description of what arguments can legitimately be passed to the
function COMPILE in CLtL is too vague. There are two specific
problems:
(1) Acceptance of the FUNCTION-TYPE proposal makes it nonsensical to
speak of a lambda-expression being an interpreted function (it is not)
or to require a symbol to have a lambda-expression as its definition
(the SYMBOL-FUNCTION must be a true FUNCTION object).
(2) Many implementations cannot correctly compile functions that are
defined interpretively in a non-null lexical environment, because the
compiler and interpreter use different representations for closures.
Although this problem arose in conjunction with the
DEFINING-MACROS-NON-TOP-LEVEL proposal, the situation can also arise
if SETF is used to store a lexical closure in the SYMBOL-FUNCTION of
the symbol.
Proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY:
If the optional "definition" argument to COMPILE is supplied, it may
be either a lambda expression (which is coerced to a function) or a
function to be compiled. Otherwise, the SYMBOL-FUNCTION of the symbol
is extracted and compiled. It is an error if the function to be
compiled was defined interpretively in a non-null lexical environment,
or if it is already compiled.
Rationale:
Saying "it is an error" to try to compile the wrong kind of function
allows implementations that can compile functions defined in a
non-null lexical environment to go ahead and do so.
Current Practice:
Implementations that do not allow sharing of lexical environments
between compiled and interpreted functions include VaxLisp, Allegro
CL, and Lucid. Lucid and VaxLisp already accept an interpreted function
object as the "definition" argument to COMPILE.
Cost to implementors:
Most of the changes required for this proposal are already necessary
to correctly implement the FUNCTION-TYPE proposal. The primary addition
is that COMPILE must be extended to accept a FUNCTION object as well
as a lambda expression as the "definition" argument.
Cost to users:
None. This is an upward-compatible change, since a lambda expression
can still be passed as an argument to COMPILE. Also, since most
existing implementations refuse to compile a function with a non-empty
lexical environment, user code which depends on being able to do this
is already nonportable.
Benefits:
An area of ambiguity in the language is resolved.
Discussion:
An alternative behavior when trying to COMPILE as function that is
already compiled would be to do nothing.
-------
∂23-Sep-88 1054 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:54:38 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28938; Fri, 23 Sep 88 11:53:11 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02502; Fri, 23 Sep 88 11:53:08 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231753.AA02502@defun.utah.edu>
Date: Fri, 23 Sep 88 11:53:07 MDT
Subject: issue EVAL-WHEN-NON-TOP-LEVEL
To: x3j13@sail.stanford.edu
Issue: EVAL-WHEN-NON-TOP-LEVEL
References: CLtL p. 69-70
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION, ENHANCEMENT
Edit History: 6-May-88, V1 by Sandra Loosemore
Problem Description:
The current description of how the compiler should handle EVAL-WHEN
only makes sense when it appears as a top-level form in the file being
compiled. Other proposals being considered by the compiler cleanup
committee require that we clarify how the compiler should process
EVAL-WHENs appearing at non-top-level, such as within LET or FUNCTION
special forms.
Proposal: EVAL-WHEN-NON-TOP-LEVEL:CLARIFY
In this proposal, we view EVAL-WHEN as a macro which expands into a
PROGN containing the body of the EVAL-WHEN when the context in which it
is expanded matches one of the situations listed, or NIL otherwise.
However, it is explicitly *not* proposed that EVAL-WHEN's status as
a special form be changed.
The EVAL situation corresponds to the normal processing of the
interpreter. If EVAL is specified, the interpreter evaluates each
form in the body of the EVAL-WHEN as an implicit PROGN, using the
current lexical environment. If the EVAL situation is not specified,
then the interpreter must return NIL as the value of the EVAL-WHEN
form, without evaluating the body.
The LOAD situation corresponds to the normal processing of the
compiler. If LOAD is specified, the compiler treats the EVAL-WHEN as
a PROGN and compiles the body in the normal way in the appropriate
lexical environment. Otherwise, the form is equivalent to specifying
a constant value of NIL. (The name LOAD is something of a misnomer,
because ``evaluation'' of the body happens not at LOAD time, but when
the EVAL-WHEN form would normally be ``evaluated''. For example, if
an EVAL-WHEN form appears in the body of a DEFUN, it is ``evaluated''
when that function is called.)
The COMPILE situation is a special case; it indicates that the
compiler itself should evaluate the body of the EVAL-WHEN form as an
implicit PROGN in the null lexical environment. During the
evaluation, if a nested EVAL-WHEN appears in the body, the interpreter
follows its usual rule of checking only whether or not the EVAL
situation is specified to decide whether or not the body of the nested
EVAL-WHEN should be processed.
If both the COMPILE and LOAD situations are specified, the compiler
first performs the evaluation for the COMPILE situation. Then, the
normal processing for the LOAD situation takes place, except that the
compile-time evaluation of nested (EVAL-WHEN (COMPILE) ...) forms in
the body is suppressed, preventing repeated evaluations of subforms.
(EVAL-WHEN (COMPILE) ...) should be used with caution in non-top-level
situations. For example, if the following appears as a top level form
in a file being compiled
(let ((x (some-hairy-computation)))
(eval-when (eval compile load) (print x)))
the variable X will be treated as special during the compile-time
evaluation, and the value printed will be its symbol-value. To
guarantee consistency between compile-time evaluation and the normal
processing, one should wrap the entire top-level form in an EVAL-WHEN,
as follows:
(eval-when (eval-compile load)
(let ((x (some-hairy-computation)))
(print x)))
Rationale:
The behavior of top-level EVAL-WHENs as specified in this proposal
remains almost identical to that specified in CLtL. The major
addition is specifying the lexical environment in which non-top-level
EVAL-WHENs are processed. It is clear that the COMPILE situation must
always be processed in the null lexical environment, since the actual
lexical environment is not available at compile time. Having the EVAL
and LOAD situations evaluate in the proper environment leads to
differing semantics, but it appears to be the behavior that most
people expect, and it is also the easiest to implement.
Suppression of COMPILE evaluations in nested EVAL-WHENs is necessary
to achieve certain desirable behaviors, such as the macro example in
section 4 of the DEFINING-MACROS-NON-TOP-LEVEL proposal.
Although viewing EVAL-WHEN as a macro is useful for purposes of
explanation, user code is likely to want to continue to treat EVAL-WHEN
as a special form. For example, a preprocessor that performs a code
walk should leave EVAL-WHENs intact, since the context in which the
preprocessor runs may not be the same as the context in which the code
it produces runs.
Current Practice:
Cost to implementors:
Probably fairly minor in most implementations.
As an implementation technique, we suggest implementing EVAL-WHEN as a
macro which uses a state variable to keep track of the current context.
A sample implementation might look something like:
(defvar *compiling-p* nil "Are we compiling or interpreting?")
(defmacro eval-when (situations &body body)
(cond
;; If the COMPILE situation applies, evaluate the body now
;; and also see if we need to do the LOAD situation too.
;; If so, shadow the definition of EVAL-WHEN to make it
;; ignore nested compile-time evaluation requests, and
;; return the body.
((and *compiling-p* (member 'compile situations))
(eval `(progn ,@body))
(if (member 'load situations)
`(macrolet ((eval-when (situations &body body)
(if (member 'load situations)
`(progn ,@body)
'nil)))
,@body)
'nil))
;; If either the EVAL or LOAD situation applies, return a PROGN.
((if *compiling-p*
(member 'load situations)
(member 'eval situations))
`(progn ,@body))
;; Otherwise no situation applies, so just return NIL.
(t
'nil)))
;;; Eval must bind *compiling-p* to NIL.
(defun eval (form)
(let ((*compiling-p* nil))
:
))
;;; Compile and Compile-file must bind *compiling-p* to a non-nil value.
(defun compile (name &optional definition)
(let ((*compiling-p* t))
:
))
(defun compile-file (input-pathname &key output-file)
(let ((*compiling-p* t))
:
))
Cost to users:
Since CLtL does not currently specify what the meaning of EVAL-WHEN
forms at non-top-level is, existing code which depends on their use is
already nonportable. Preventing repeated evaluations of subforms when
EVAL-WHENs are nested is unlikely to cause any serious compatibility
problems, since the current model would already result in only a
single evaluation in the case when the code is processed
interpretively.
There are also some situations concerning nested top-level occurences
of EVAL-WHEN that CLtL does not completely specify, to which this
proposal does assign a specific interpretation. For example, CLtL is
unclear on whether or not (FOO) would ever be called, while in the
current proposal it would definitely not be called:
(eval-when (compile)
(eval-when (compile)
(foo)))
Benefits:
Clarifying the meaning of EVAL-WHEN allows the behavior of defining
macros such as DEFMACRO to be specified in terms of EVAL-WHEN. As a
side effect, it would then become meaningful for defining macros to
appear at other than top-level.
Discussion:
This proposal reflects what appears to be the consensus of the
compiler cleanup committee on this issue.
-------
∂23-Sep-88 1058 X3J13-mailer **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:57:54 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA29038; Fri, 23 Sep 88 11:56:26 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02532; Fri, 23 Sep 88 11:56:23 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231756.AA02532@defun.utah.edu>
Date: Fri, 23 Sep 88 11:56:22 MDT
Subject: **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY
To: x3j13@sail.stanford.edu
Issue: COMPILE-ENVIRONMENT-CONSISTENCY
References: CLtL p. 68-69, 143, 321
RAM's "Compiler Cleanup Proposal #3"
Category: CLARIFICATION
Edit History: V1, 2 Sep 1988, Sandra Loosemore (initial draft)
V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions)
Status: **DRAFT**
Problem Description:
CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled.
Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:
Common Lisp deliberately leaves unspecified the time at which certain
transformations, such as macro expansion, are performed within a
program. While some implementations perform such transformations
concurrently with evaluation, it is also legitimate to perform
transformations during a preprocessing phase. For example, an
implementation might choose to apply transformations at "function
promotion time" (i.e., transformations are applied once during
evaluation of a surrounding FUNCTION special form), or to completely
transform each top-level form and all of its subforms before
performing any evaluation. User programs cannot portably depend upon
either the time of such transformations, or the number of times the
transformations are applied.
In all cases, however, compiling a program (with COMPILE or
COMPILE-FILE) provides a mechanism for forcing these transformations
to be applied and a guarantee that, once compiled, no further
transformations will be applied to that program.
In the discussion that follows, the term "compiler" is to be understood
to include other preprocessors as well. Likewise, the "compiletime
environment" refers to the environment in which program transformations
occur, while "runtime" refers to the time the program is executed.
(1) The following information *must* be present in the compiletime
environment for the preprocessor to apply the correct transformations.
This information need not also be present in the runtime environment.
(a) Macro definitions must be available in the compiletime environment.
The compiler may assume that forms that are lists beginning with
a symbol that does not name a macro or special form is a function
call. (This implies that SETF methods must also be available at
compiletime.)
(b) Special variables must be declared as such before they are bound.
The compiler must treat any undeclared variable binding as a
lexical binding.
(2) The compiler *may* "wire in" the following kinds of information
into the code it produces, if the information is present in the
compiletime environment. However, since implementations are not
required to do this, user code must ensure that the information is
also defined consistently in the runtime environment. Except as
noted, the behavior of user programs is unspecified in situations
where the information is defined differently at runtime than at
compiletime, since the user cannot depend upon which will take
precedence in a particular implementation. In all cases, the absence
of the information at compiletime is not an error, but its presence
may enable the compiler to do a better job.
(a) The compiler may assume that functions that are defined and
declared INLINE in the compiletime environment will retain the
same definitions at runtime.
(b) The compiler may assume that, within a named function, a
recursive call to a function of the same name refers to the
same function, unless that function has been declared NOTINLINE.
(c) COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at runtime.
(d) The compiler may assume that the signature (or "contract") of
all built-in Common Lisp functions will not change. In addition,
the compiler may treat all built-in Common Lisp functions as if
they had been proclaimed INLINE.
(e) The compiler may "wire in" the values of symbolic constants
that have been defined with DEFCONSTANT in the compiletime
environment.
(f) Types that are defined with DEFTYPE or DEFSTRUCT can be assumed to
retain the same definition in the runtime environment as in the
compiletime environment. (Note that it is not an error for an
unknown type to appear in a declaration at compiletime, although
it is reasonable for the compiler to emit a warning in such a
case.)
(g) The compiler may assume that a class name defined by DEFCLASS
that is present in the compiletime environment will also be a
class name at runtime, and that class will be an instance of the
same metaclass. There may be additional conformance requirements
imposed by the metaclass, but there are none for STANDARD-CLASS.
(h) The compiler may assume that if type declarations are present
in the compiletime environment, the corresponding variables and
functions present in the runtime environment will actually be of
those types; otherwise, the behavior of the program is undefined.
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not assume that functions that are defined
in the compiletime environment will retain the either the
same definition or the same signature at runtime, except
in situations (2a) through (2d) above. It is, however,
reasonable for the compiler to emit warning messages about
calls to functions that are defined at compiletime, but where
the wrong number or type of arguments are supplied.
(b) The compiler may not signal an error if it sees a call to a
function that is not defined at compiletime, since that function
may be provided at runtime. Again, it is permissible to emit
a warning in these situations.
Rationale:
This proposal generally reflects current practice.
Current Practice:
I know of no compiler that does not implement the provisions of item (1).
For item (2), most compilers (including Lucid) optimize self-recursive
calls by default. Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well. VaxLisp, for
example, normally compiles MEMBER inline. The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining. KCL performs block compilation by default,
and Lucid does so under certain conditions.
Cost to implementors:
Unknown, but probably minor.
Cost to users:
Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.
Benefits:
The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.
Discussion:
Most of the discussion on this issue has been centered on the
terminology describing error situations for item (2). In most cases
where there is an inconsistency between compile-time and run-time, the
results will be unpredictable but harmless. The major exception is
violation of type declarations, which is a "crash-and-burn" error in
many implementations.
There has also been some concern raised that item (3) would prohibit
such things as a cross-compiler that produces standalone programs in
an environment that disallows redefinition of functions. The intent
of this proposal is not to prohibit a compiler from having a magic
switch that imposes additional restrictions on the programs it
compiles, but such a compiler would not be a compiler for Common Lisp.
-------
∂23-Sep-88 1054 X3J13-mailer issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:54:04 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28914; Fri, 23 Sep 88 11:52:40 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02497; Fri, 23 Sep 88 11:52:36 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231752.AA02497@defun.utah.edu>
Date: Fri, 23 Sep 88 11:52:35 MDT
Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
To: x3j13@sail.stanford.edu
Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
References: CLtL pages 66-70, 143
Category: CLARIFICATION
Edit history: V1, 07 Oct 1987 Sandra Loosemore
V2, 15 Oct 1987 Sandra Loosemore
V3, 15 Jan 1988 Sandra Loosemore
V4, 06 May 1988 Sandra Loosemore
V5, 20 May 1988 Sandra Loosemore
V6, 09 Jun 1988 Sandra Loosemore
Problem Description:
Standard programming practices assume that, when calls to defining
macros such as DEFMACRO and DEFVAR are processed by COMPILE-FILE,
certain side-effects occur that affect how subsequent forms in the
file are compiled. However, these side-effects are not mentioned in
CLtL, except for a passing mention that macro definitions must be
``seen'' by the compiler before it can compile calls to those macros
correctly. In order to write portable programs, users must know
exactly which defining macros have compile-time side-effects and what
those side-effects are.
Inter-file compilation dependencies are distinct from, and not
addressed by, this issue.
Proposal: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
(1) Clarify that defining macros such as DEFMACRO or DEFVAR, appearing
within a file being processed by COMPILE-FILE, normally have
compile-time side effects which affect how subsequent forms in the
same file are compiled. A convenient model for explaining how these
side effects happen is that the defining macro expands into one or
more EVAL-WHEN forms, and that the calls which cause the compile-time
side effects to happen appear in the body of an (EVAL-WHEN (COMPILE)
...) form. This is also the recommended implementation technique.
(2) The affected defining macros and their specific side effects are
as follows:
DEFTYPE: The body of a DEFTYPE form must be evaluable at compile time.
If the expansion of a DEFTYPE'd type specifier is also a valid type
specifier at compile time, then the DEFTYPE'd type specifier is also
considered to be fully defined at compile time and must be recognized
within subsequent type declarations.
DEFMACRO, DEFINE-MODIFY-MACRO: Macro definitions must be stored at compile
time, so that occurences of the macro later on in the file will be expanded
correctly. The body of the macro (but not necesarily its expansion) must
be evaluable at compile time.
DEFUN: An implementation may choose to store information about the
function for the purposes of compile-time error-checking (such as
checking the number of arguments on calls), or to enable the function
to be expanded inline. Portable code should not rely on DEFUN making
the function definition available at compile time.
DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
named by these forms have been proclaimed special. The initial value
form must not be evaluated at compile time.
DEFCONSTANT: The compiler must recognize the symbol as being constant
(for example, to suppress warnings about references to the symbolic
constant as an unbound variable or to enable warnings about binding or
SETQ'ing the constant in the code being compiled). Neither evaluation
of the value-form or SETQ'ing of the symbol may occur at compile-time.
However, if the (unevaluated) value-form is CONSTANTP, the compiler is
allowed to build assumptions about the value of the constant into
programs being compiled, as described on p. 68-69 of CLtL.
DEFSETF, DEFINE-SETF-METHOD: SETF methods must be available during the
expansion of calls to SETF later on in the file. The body of
DEFINE-SETF-METHOD and the complex form of DEFSETF must be evaluable
at compile time, although the expansions need not be.
DEFSTRUCT: The structure type name must be recognized as a valid type name
in declarations, as for DEFTYPE. The structure slot accessors must be made
known to SETF. In addition, further DEFSTRUCT definitions should be able
to :INCLUDE a structure type defined earlier in the file being compiled.
The functions which DEFSTRUCT generates, and the #S reader syntax, may or
may not be available at compile time.
(3) The compile-time side effects may cause information about the
definition to be stored differently than if the defining macro had
been processed in the "normal" way (either interpretively or by loading
the compiled file).
In particular, the information stored by the defining macros at
compile time may or may not be available to the interpreter (either
during or after compilation), or during subsequent calls to COMPILE or
COMPILE-FILE. For example, the following code is nonportable because
it assumes that the compiler stores the macro definition of FOO where
it is available to the interpreter:
(defmacro foo (x) `(car ,x))
(eval-when (eval compile load)
(print (foo '(a b c))))
A portable way to do the same thing would be to include the macro definition
inside the EVAL-WHEN:
(eval-when (eval compile load)
(defmacro foo (x) `(car ,x))
(print (foo '(a b c))))
Rationale:
The proposal reflects standard programming practices. The primary
purpose of the proposal is to make an explicit statement that CL
supports the behavior that most programmers expect and many
implementations already provide.
Current Practice:
Many (probably most) Common Lisp implementations, including VaxLisp
and Lucid Lisp, are already largely in conformance.
In VaxLisp, macro definitions that occur as a side effect of compiling
a DEFMACRO form are available to the compiler (even on subsequent calls
to COMPILE or COMPILE-FILE), but are not available to the interpreter
(even within the file being compiled).
Kyoto Common Lisp is a notable offender. By default, KCL evaluates *all*
top level forms as they are compiled, which is clearly in violation of the
behavior specified on p 69-70 of CLtL. There is a flag to disable the
compile-time evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do
not make their definitions available at compile-time either.
Cost to implementors:
Making the defining macros expand into EVAL-WHENs to store the required
information is a simple and recommended implementation technique. The
intent of the proposal is specifically not to require the compiler to
have special knowledge about each of these macros.
Cost to users:
Since CLtL does not specify whether and what compile-time side-effects
happen, any user code which relies on them is, strictly speaking,
nonportable. In practice, however, most programmers already expect
the behavior described in this proposal and will not find it to be
an incompatible change.
Benefits:
Adoption of the proposal will provide more definite guidelines on how to
write programs that will compile correctly under all CL implementations.
Discussion:
Reaction to an earlier version of this proposal on the CL mailing list was
overwhelmingly positive.
It has been suggested that this proposal should also include PROCLAIM.
However, since PROCLAIM is not a macro, its compile-time side effects
cannot be handled using the EVAL-WHEN mechanism. A separate proposal
seems more appropriate.
There has also been a suggestion that DEFCONSTANT should always
evaluate the value provided. The behavior specified in this proposal
makes DEFCONSTANT similar to DEFVAR and DEFPARAMETER, while allowing
the user to explicitly ask for compile-time evaluation using the #. read
macro.
Item (3) allows for significant deviations between implementations.
While there is some sentiment to the effect that the compiler should
store definitions in a manner identical to that of the interpreter,
other people believe strongly that compiler side-effects should be
completely invisible to the interpreter. The author is of the opinion
that since this is a controversial issue, further attempts to restrict
this behavior should be considered as separate proposals.
-------
∂23-Sep-88 1058 X3J13-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:58:36 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA29064; Fri, 23 Sep 88 11:57:04 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02537; Fri, 23 Sep 88 11:57:00 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231757.AA02537@defun.utah.edu>
Date: Fri, 23 Sep 88 11:56:59 MDT
Subject: **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE
To: x3j13@sail.stanford.edu
Issue: PROCLAIM-ETC-IN-COMPILE-FILE
References: CLtL p. 182 [package functions],
p. 156 [PROCLAIM], P. 188 [REQUIRE],
p. 439 [COMPILE-FILE];
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Category: CLARIFICATION
Edit History: 15 Sept. 88, V1 by David Gray
23 Sep 88, V2 by Sandra Loosemore (summarize discussion)
Status: **DRAFT**
Problem Description:
Page 182 of CLtL says that COMPILE-FILE needs to treat top-level calls
to the following package functions as though they were wrapped in an
(EVAL-WHEN (COMPILE LOAD EVAL) ...):
EXPORT IMPORT IN-PACKAGE MAKE-PACKAGE SHADOW
SHADOWING-IMPORT UNEXPORT UNUSE-PACKAGE USE-PACKAGE
There are other things that need special handling by the compiler that
are not explicitly specified by CLtL. The proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY addresses the part of
the problem pertaining to macros that define things. The following
proposal adds PROCLAIM and REQUIRE to the list of functions needing
special handling.
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:CLARIFY:
Clarify that when COMPILE-FILE encounters a call to one of the following
functions at top level in a file, the form will be evaluated at compile
time as well as at load time:
EXPORT IMPORT IN-PACKAGE MAKE-PACKAGE PROCLAIM REQUIRE SHADOW
SHADOWING-IMPORT UNEXPORT UNUSE-PACKAGE USE-PACKAGE
Note that the compile-time evaluation of these package functions can
affect the way that the remaining top-level forms in the file are read.
In the case of PROCLAIM, it is implementation-dependent whether the
evaluation affects the global environment or is only recorded in data
structures used by the compiler, and whether the effect of the
evaluation remains in the global environment after COMPILE-FILE returns.
(PROCLAIM '(OPTIMIZE ...)) is a special case that is evaluated only at
compile-time and not at load time, and that affects only the current
file being compiled.
Note that the behavior specified here can still be altered by the
user by wrapping an explicit EVAL-WHEN around the form.
Rationale:
Experience seems to have shown that this behavior best matches what
people expect to have happen. The examples on pages 189 and 191 of CLtL
won't work right unless REQUIRE takes effect at compile-time. Since
most of the things that PROCLAIM can be used for only affect the
compiler, it doesn't make much sense for the compiler to not take notice
during compilation. Optimization control is something that one usually
wants to control locally, rather that having a proclamation in one file
affect other unrelated files compiled later.
Current Practice:
This proposal follows what the Explorer does, except that (EVAL-WHEN
(LOAD) (PROCLAIM '(OPTIMIZE ...))) doesn't do anything. The Symbolics
compiler has special top-level handling for all of these functions,
although the details are not clear. The Lucid documentation indicates
that certain functions at top-level are treated as though within an
(EVAL-WHEN (EVAL COMPILE LOAD) ...): REQUIRE, all of the package
functions listed above, INTERN, and UNINTERN; it is not clear what
happens with PROCLAIM.
Cost to implementors:
Since implementations are already required to have a mechanism for
compile-time handling of the package functions, it should only require
minor adjustments to add handling for PROVIDE and REQUIRE if they aren't
handled already. The main thing that most implementations would need to
do is to make OPTIMIZE proclamations local to the file, but that should
be fairly simple.
Cost to users:
If someone has a use of REQUIRE that they want to only be a load-time
dependency and their implementation did not previously do REQUIRE at
compile-time, they may want to wrap (EVAL-WHEN (EVAL LOAD) ...) around
it.
If someone has a use of (PROCLAIM '(OPTIMIZE ...)) that they really want
to be global, they would need to wrap (EVAL-WHEN (EVAL COMPILE LOAD)
...) around it.
Benefits:
Users will know what to expect when they use PROCLAIM and REQUIRE.
Costs of Non-Adoption:
In order to write programs that would be sure to be portable, the user
would have to wrap an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around each use
of PROCLAIM or REQUIRE in order to be sure of what will happen.
Aesthetics:
Programs look cleaner if EVAL-WHEN is only needed for unusual cases
instead of being required for the normal cases.
Discussion:
Cleanup proposal PROCLAIM-SCOPE:ADD-KEYWORD-PERVASIVE wanted to add an
option to PROCLAIM to control whether the effect is local to the current
file. That may be better handled by an extension to EVAL-WHEN since
that kind of control might be wanted for definitions as well as
proclamations. If the handling of OPTIMIZE specified here is taken as a
default, that issue can be pursued separately from this one.
There have been objections raised to treating (PROCLAIM '(OPTIMIZE...))
specially.
If DEFPACKAGE is accepted, we may wish to remove the "magical" behavior
of the package functions entirely, and propose a macro (DEFPROCLAIM?)
to deal with PROCLAIM. How do people feel about making this kind of
incompatible change to the language?
-------
∂23-Sep-88 1055 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:55:13 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28959; Fri, 23 Sep 88 11:53:47 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02507; Fri, 23 Sep 88 11:53:43 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231753.AA02507@defun.utah.edu>
Date: Fri, 23 Sep 88 11:53:41 MDT
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL
To: x3j13@sail.stanford.edu
Issue: DEFINING-MACROS-NON-TOP-LEVEL
References: CLtL p. 66-70, 143
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Category: CLARIFICATION, ENHANCEMENT
Edit History: 6-May-88, V1 by Sandra Loosemore
9-Jun-88, V2 by Sandra Loosemore
12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)
21-Sep-88, V4 by Sandra Loosemore (clarify section 5)
Problem Description:
CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unspecified.
Resolution of other issues (EVAL-WHEN-NON-TOP-LEVEL and
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS) now allows reasonable
semantics to be assigned to defining forms which appear at
non-top-level.
Proposal: DEFINING-MACROS-NON-TOP-LEVEL:ALLOW
(1) Clarify that while defining macros normally appear at top level,
it is meaningful to place them in non-top-level contexts and that the
compiler must handle them properly in all situations. Remove the
language on p. 66 of CLtL which states that the compiler is not
required to recognize defining macros at other than top-level.
(2) The proposal COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
defines a model for specifying how defining macros work. To
summarize, the expansion of the macro (rather than its expander
function) is responsible for storing information about the definition.
Compile-time side effects are typically handled by including one or
more EVAL-WHEN forms in the expansion. A compiler may choose
some other implementation, such as treating defining macros as
implementation-specific special forms, provided that the semantics
are compatible.
(3) Defining macros which define functional objects (such as DEFUN and
DEFMACRO) must ensure that the functions are defined in the lexical
environment in which the defining macro appears. In the model
referred to above, this would normally be implemented by producing a
FUNCTION special form in the macro expansion. For example, the
following code causes the function BAR to be closed over the variable
X:
(let ((x (some-hairy-computation)))
(defun bar (y) (+ x y)))
(4) The language on p. 145 of CLtL, which states that macro functions
are always defined in the null lexical environment, should be removed.
Instead, the defining forms DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and
the complex form of DEFSETF, which make functional definitions
available at compile time, use the environment which is apparent at
the time of evaluation. When calls to these macros appear in a
non-null lexical environment, an explicit (EVAL-WHEN (COMPILE) ...)
must normally be wrapped around the entire containing top-level form
to ensure that the correct lexical environment is seen at both compile
time and load time.
An example may help clarify why this is necessary. The code fragment
(let ((x (some-hairy-computation)))
(defmacro bar-macro (y) `(+ ,x ,y)))
would macroexpand into something similar to
(let ((x (some-hairy-computation)))
(eval-when (eval compile load)
(setf (macro-function 'bar-macro)
#'(lambda (form env)
(let ((y (second form)))
`(+ ,x ,y))))
'bar-macro))
Since the rules for (EVAL-WHEN (COMPILE) ...) state that evaluation
takes place in the null lexical environment, in this situation X would
be treated as a special variable within the macro function. However,
in the EVAL or LOAD situations, the lexical value of X would be used.
To ensure consistency, the correct definition would be:
(eval-when (eval compile load)
(let ((x (some-hairy-computation)))
(defmacro bar (y) `(+ ,x ,y))))
(5) Clarify that ``top-level forms'' are evaluable data objects read
in from an input source (such as a keyboard or disk file) by
successive calls to the function READ; these forms would be evaluated
by the interpreter in a null lexical environment. As special cases,
forms within a top-level PROGN or COMPILER-LET are also considered to
be top-level forms, as is the expansion of a macro call appearing at
top-level. Specify that top-level forms in a file being compiled are
guaranteed to be processed sequentially, but the order in which
subforms of a top-level form are processed by the compiler is
explicitly left unspecified. It is an error for user code to depend
upon the compile-time side-effects of a defining macro within the same
top-level form in which the defining macro appears.
Rationale:
The notion of a ``top-level form'' is rather confused, since the term
is used in CLtL to refer both to a place where a form may appear (what
this proposal continues to call ``top-level''), and to instances of
forms which traditionally appear there (what this proposal calls
``defining macros'').
There has been a suggestion that the notion of a top-level form should
be extended to include forms in the body of a top-level LET, to allow
forms such as DEFUN to be meaningful there. However, we feel that a
cleaner solution is to remove the restrictions on the placement of
defining macros altogether.
Current Practice:
CLtL mentions only that forms within a top-level PROGN, and not
COMPILER-LET, are treated as top-level. However, COMPILER-LET is
also treated specially in implementations derived from the MIT Lisp
Machine (TI and Symbolics), as well as Lucid and Coral (but not
VaxLisp).
Cost to implementors:
Cost to users:
None. This is a compatible extension.
Benefits:
The notion of defining macros as being somehow special is removed from
the language. Allowing defining macros to appear anywhere instead of
restricting them to certain positions results in a cleaner language
design.
Discussion:
-------
∂23-Sep-88 1212 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 12:12:09 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 23 Sep 88 15:11:42 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 23 Sep 88 15:09:39 EDT
Date: Fri, 23 Sep 88 15:10 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8809231753.AA02507@defun.utah.edu>
Message-Id: <19880923191014.6.BARMAR@OCCAM.THINK.COM>
Date: Fri, 23 Sep 88 11:53:41 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Specify that top-level forms in a file being compiled are
guaranteed to be processed sequentially, but the order in which
subforms of a top-level form are processed by the compiler is
explicitly left unspecified. It is an error for user code to depend
upon the compile-time side-effects of a defining macro within the same
top-level form in which the defining macro appears.
I don't understand this part. Could you give an example of code that
has such a dependency?
barmar
∂26-Sep-88 0931 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:31:16 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465233; Sun 25-Sep-88 15:09:13 EDT
Date: Sun, 25 Sep 88 15:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue EVAL-WHEN-NON-TOP-LEVEL
To: sandra%defun@cs.utah.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8809231753.AA02502@defun.utah.edu>
Message-ID: <880925150859.4.KMP@GRYPHON.SCRC.Symbolics.COM>
I'm sorry. At the last meeting, I stated that I had reservations about
this proposal and said I would send some mail and I never did. I did say
at that time, though, that the root of my problem was that there were
insufficient examples and that this made me nervous because this is a
hard issue to reason about and (I think) an easy one to get wrong.
-- Specific Remarks --
Your use of phrases like "the interpreter" in the proposal make me
nervous because I work with at least one compiled-only implementation
(Cloe).
Your remarks about
(let ((x (some-hairy-computation)))
(eval-when (eval compile load) (print x)))
treating X as special in the compile situation are not supported by any
part of CLtL that I know of. X is treated as "free", but that situation
is not defined by CLtL as far as I know.
Btw, I don't see why the term "hairy" needs to be in that example.
The issue would be the same for a trivial computation.
Your references to EVAL being like "normal processing of the interpreter"
and LOAD being like "normal processing of the compiler" are too obscure
for me to figure out. Perhaps you mean "normal execution of interpreted
code" and "normal execution of compiled code"? If so, I might begin to see
what you mean, but since the presence of compiled-only and interpreted-only
implementations makes these phrases vague, I'd want to see this clarified.
I am also unconvinced that LOAD really corresponds to "normal execution".
In my code, it often addresses things that really only want to be done
once and never again because at top-level, things can't happen more than
once. I'm not at all clear that if I had a DEFFOO macro which expanded
into (EVAL-WHEN (LOAD) ...) and someone put the DEFFOO in the body
of (DEFUN BAR ...) -- a thing you're apparently advocating -- that I
would want the thing in the LOAD clause executing every time they called
BAR.
Also, you don't offer enough info for me to figure out what happens when
both EVAL and LOAD are specified in the interpreter.
In general, the absence of examples makes this just hard to follow.
-- General Remarks --
I believe that the real problem with EVAL-WHEN is that its keywords do
not map straightforwardly onto the things we really need to say. For
example, when we really want to do something abstract like "provide
macro support at semantic analysis time" we are instead forced to
designate times (EVAL COMPILE) because we happen to know that that is
when semantic analysis takes place and we must cover our bets.
I think there is no fix for EVAL-WHEN other than to identify keywords
which are equally meaningful to interpreter-only and compiled-only
implementations. I would rename COMPILE to something meaning ``semantic
analysis time,'' LOAD to something meaning ``first occurrence in
execution environment'' and EVAL to mean something like ``execution
time.'' But then I would also want to require interpreted-only
implementations to do a semantic-prepass so that ``semantic analysis
time'' where all macros were expanded at once and all EVAL-WHEN's
figured out at a definite time rather than being permitted to occur
lazily.
Since I don't really feel convinced about what you're proposing and since
I think what I might propose is a ``research'' project too ambitious
to get into at this point, I would prefer that EVAL-WHEN continue to
be illegal except at toplevel and that we just pin down a status-quo
description of what EVAL-WHEN already does, asking Kathy to acknowledge
in the manual that we know its design is less than pretty and that
the design of a better primitive is a research topic.
∂26-Sep-88 0931 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:31:39 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465246; Sun 25-Sep-88 16:59:01 EDT
Date: Sun, 25 Sep 88 16:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)
To: sandra%defun@cs.utah.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8809231753.AA02507@defun.utah.edu>
Message-ID: <880925165852.8.KMP@GRYPHON.SCRC.Symbolics.COM>
Since this proposal is apparently (although not explicitly) dependent on
your EVAL-WHEN-NON-TOP-LEVEL:CLARIFY, and since I don't support that
proposal, it shouldn't come as a surprise that I can't support this one.
In addition to whatever comments might carry through from my objections
to that proposal, however, I also have these concerns:
* I don't think the nesting under the proposed definition of DEFMACRO
is consistent. Consider:
(DEFUN FOO ...
(DEFMACRO BAR ...))
Under your proposed EVAL-WHEN semantics, the definition of BAR will
be available at compile time for all forms following FOO's definition,
but it will not become available at runtime until FOO is called.
This strikes me as very baroque.
* We have a charter to do something about establishing normative
practice. When McCarthy was visiting, he suggested that one thing
that goes with that is making sure that if you're encouraging people
to do something, it's something you can reasonably expect to support
efficiently. It follows, I think, that if you change the language
to encourage people to do DEFUN inside of DEFUN, DEFMETHOD inside of
DEFMETHOD, etc., you'd better make it efficient. In fact, though,
many implementations do lots of "junk" at compiled file load time
which you wouldn't want executed every time you ran a function.
* For the most part, it doesn't make any sense to do
(DEFUN ... (DEFUN ...)) so it seems strange to encourage it.
The only practical reason I can think of for doing this is to do
some sort of module facility where you selectively activate definitions
that you need by calling the outer function. I think this is what
LOAD and packages are already in CL for, and although I don't think they
are the answer to all the world's problems, they are better than
doing nested defuns.
* The Scheme language attaches a very different meaning to
(DEFUN FOO (X)
(DEFUN BAR (X) ...) ... (BAR ...) ...)
than we do. I've seen novices screwed by doing this and having it work.
[It does in most interpeters.] They -think- they are getting a local
function when really they're getting BAR globally redefined every time
they run FOO. They don't find out until they do
(DEFUN BAZ (X)
(DEFUN BAR (X) ...) ... (BAR ...) ...)
and start calling FOO and BAZ in complicated, mutually recursive situations
with BAR getting clobbered back and forth until disaster finally strikes.
The CL style for local definitions is LABELS, FLET, etc. and I think
we should just stick to that.
I don't pretend that these are all the objections that I would have if I
thought for more than ten minutes on this issue, but they seem to me to
be sufficiently major to warrant some pretty careful thought before
proceeding on this.
I would prefer that defining forms just be restricted to toplevel
because we don't have time in the next three months to do any better
than that.
∂26-Sep-88 0931 X3J13-mailer issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:31:39 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 465244; 25 Sep 88 16:41:52 EDT
Date: Sun, 25 Sep 88 16:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
To: sandra%defun@cs.utah.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8809231752.AA02497@defun.utah.edu>
Message-ID: <880925164139.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Sorry about the delay in replying. I have a number of comments
about this proposal...
Date: Fri, 23 Sep 88 11:52:35 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Ultimately, I expect to support this proposal though I have some
reservations about many sections in the current draft...
(1) Clarify that defining macros such as DEFMACRO or DEFVAR, ...
A convenient model for explaining how these side effects happen is
that the defining macro expands into one or more EVAL-WHEN forms ...
This is also the recommended implementation technique.
This last sentence is gratuitous. It adds nothing to the proposal
and makes me very nervous. For example:
(PROGN (PROCLAIM '(SPECIAL *WHATEVER*))
(SETQ *WHATEVER* 3))
is a better expansion for DEFVAR than anything involving EVAL-WHEN.
As another example, many implementations get by fine with DEFUN
turning into
(SETF (SYMBOL-FUNCTION 'WHATEVER) #'(LAMBDA ...))
DEFTYPE: The body of a DEFTYPE form must be evaluable at compile time.
If the expansion of a DEFTYPE'd type specifier is also a valid type
specifier at compile time, then the DEFTYPE'd type specifier is also
considered to be fully defined at compile time and must be recognized
within subsequent type declarations.
If it uses SATISFIES of a named, user-defined function in its expansion,
must the function be available at compile time for the type specifier to
be considered `valid' ? Can/should implementations give an undefined-function
warning at compile time?
DEFMACRO, DEFINE-MODIFY-MACRO: Macro definitions must be stored at compile
time, so that occurences of the macro later on in the file will be expanded
"occurrences"
correctly. The body of the macro (but not necesarily its expansion) must
"necessarily"
be evaluable at compile time.
Whether the expansion is necessary depends on whether the macro is itself used
subsequently in the file in the body of another macro being defined. eg,
(DEFMACRO FOO ...)
(DEFUN BAR-FUNCTION ... (FOO ...)) ;Needs FOO body
(DEFMACRO BAR-MACRO ... (FOO ...)) ;Needs FOO body and expansion
By similar reasoning, whether the macro body needs to be executable is not a
given. You might not plan to use the macro in the remainder of the file, in which
case it need only be compilable but not executable until load time.
The two situations seem symmetric to me in this respect, so I don't understand
the use of the asymmetric construction "The body ... (but not necesarily its
expansion) must ...".
DEFUN: An implementation may choose to store information about the
function for the purposes of compile-time error-checking (such as
checking the number of arguments on calls), or to enable the function
to be expanded inline. Portable code should not rely on DEFUN making
the function definition available at compile time.
Does this imply that it's permitted? That may make sense for COMPILE, but
it doesn't make sense for COMPILE-FILE. COMPILE-FILE should be a no-op (or
a ``copy-file'' equivalent) in interpreter-only implementations. There should
be no side-effect of doing COMPILE-FILE, so that (COMPILE-FILE "A") followed
by (LOAD "A") will load "A" only once.
DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
named by these forms have been proclaimed special. The initial value
form must not be evaluated at compile time.
DEFCONSTANT: The compiler must recognize the symbol as being constant
This sentence is pretty vacuous unless you intend to make the "for example"
items that follow into requirements (which would make this an incompatible
change for some). Do you really mean to imply anything useful by this
sentence and if so, what?
(for example, to suppress warnings about references to the symbolic
constant as an unbound variable or to enable warnings about binding or
SETQ'ing the constant in the code being compiled).
I assume these are just examples and not something you're trying to require.
Be clear.
Neither evaluation
of the value-form or SETQ'ing of the symbol may occur at compile-time.
My guess is that this might be an incompatible change for some environments.
I think some implementations permit
(DEFCONSTANT FOO 3)
(DEFCONSTANT BAR (+ FOO 1))
The effects of incompatible changes aren't really addressed adequately in
the subsequent sections. Rather than CLARIFICATION for category above, you
might want to write CLARIFICATION/CHANGE to alert people to the fact that
some (technically "non-portable", but possibly "intended to be portable")
code may be affected.
However, if the (unevaluated) value-form is CONSTANTP, the compiler is
allowed to build assumptions about the value of the constant into
programs being compiled, as described on p. 68-69 of CLtL.
DEFSETF, DEFINE-SETF-METHOD: SETF methods must be available during the
expansion of calls to SETF later on in the file. The body of
DEFINE-SETF-METHOD and the complex form of DEFSETF must be evaluable
at compile time, although the expansions need not be.
As with DEFMACRO, this depends on whether this SETF is used in the remainder
of the file. In general, I find this wording awkward because the first sentence
is a restriction on the compiler and the second is a restriction on the user
and they're just haphazardly mixed together. This isn't the only place where
that happens in this topic writeup.
DEFSTRUCT: The structure type name must be recognized as a valid type name
in declarations, as for DEFTYPE. The structure slot accessors must be made
"in subsequent declarations" ?
known to SETF. In addition, further DEFSTRUCT definitions should be able
to :INCLUDE a structure type defined earlier in the file being compiled.
The functions which DEFSTRUCT generates, and the #S reader syntax, may or
may not be available at compile time.
I'm not sure it's wise to be ambiguous on this. What's the motivation here?
(3) The compile-time side effects may cause information about the
definition to be stored differently than if the defining macro had
been processed in the "normal" way (either interpretively or by loading
the compiled file).
... In particular, ...
If you mean that
(DEFMACRO FOO ...)
(DEFMACRO BAR ... (FOO ...))
is not permissible, again your are talking [a fairly major] incompatible change
to some implementations for which you've insufficient cost analysis.
Rationale:
The proposal reflects standard programming practices.
With one or two notable exceptions, cited above.
... Current Practice: ...
Kyoto Common Lisp is a notable offender.
This statement is not adequately qualified and somewhat inflammatory.
Your current practice statement would be no less complete and somewhat
more diplomatic if you just struck this sentence altogether.
... Cost to implementors: ...
Making the defining macros expand into EVAL-WHENs to store the required
information is a simple and recommended implementation technique.
What's easy (or even desirable) in one implementation may not be in another.
I don't think you've motivated this statement adequately.
Cost to users:
Since CLtL does not specify whether and what compile-time side-effects
happen, any user code which relies on them is, strictly speaking,
nonportable. In practice, however, most programmers already expect
the behavior described in this proposal and will not find it to be
an incompatible change.
Not so in all cases. See remarks above.
Benefits:
Adoption of the proposal will provide more definite guidelines on how to
write programs that will compile correctly under all CL implementations.
I agree with the intent here, but until the issues raised above have been
addressed, I can't agree with the specifics.
Discussion:
Reaction to an earlier version of this proposal on the CL mailing list was
overwhelmingly positive....
Please don't take my reaction as negative, but don't count me as overwhelmingly
positive either.
∂26-Sep-88 1041 X3J13-mailer Re: issue EVAL-WHEN-NON-TOP-LEVEL
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 26 Sep 88 10:41:39 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA00628; Mon, 26 Sep 88 10:37:14 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
id AA16788; Mon, 26 Sep 88 10:40:00 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA18918; Mon, 26 Sep 88 10:39:55 PDT
Message-Id: <8809261739.AA18918@suntana.sun.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: sandra%defun@cs.utah.edu, x3j13@sail.stanford.edu
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL
In-Reply-To: Your message of Sun, 25 Sep 88 15:08:00 -0400.
<880925150859.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Mon, 26 Sep 88 10:39:52 -0700
From: kempf@Sun.COM
>analysis time,'' LOAD to something meaning ``first occurrence in
>execution environment'' and EVAL to mean something like ``execution
Or LOAD should mean something like "mapping of relative addresses
to absolute physical addresses", i.e. linking of separately compiled
code.
I agree that this is a thorny issue which needs more thought and
think EVAL-WHEN should remain illegal except at "top level" as
it currently is.
jak
∂26-Sep-88 1203 X3J13-mailer Hawaii hotel arrangements
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 12:03:20 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA09281g; Mon, 26 Sep 88 11:01:19 PST
Received: by challenger id AA13605g; Mon, 26 Sep 88 11:59:03 PDT
Date: Mon, 26 Sep 88 11:59:03 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809261859.AA13605@challenger>
To: X3J13@sail.stanford.edu
Subject: Hawaii hotel arrangements
We have a block of rooms reserved the 14th - 22nd of January at the Sheraton
for $80/night. Unless I change these dates you will be charged $120/night for
any dates before or after the reserved block (I know, they're bogones). If
you are planning to be there longer than the week of the conference (or arrive
earlier) please let me know ASAP what those dates are so I can try to adjust
the block to include those dates. I have to call them back Thursday morning.
Aloha,
---jan---
∂29-Sep-88 1544 X3J13-mailer Fairfax attendees
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 15:43:19 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00246g; Thu, 29 Sep 88 14:41:12 PST
Received: by challenger id AA00805g; Thu, 29 Sep 88 15:38:54 PDT
Date: Thu, 29 Sep 88 15:38:54 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809292238.AA00805@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax attendees
Thus far:
X3J13 Attendee Information
09/23/88
Name Institute Paid L1 L2
Jim Antonisse The MITRE Corporation - y -
Kim Barrett USC - - -
David Bartley TI y y y
Paul Beiser HP - y y
Danny Bobrow Xerox y y y
Skona Brittian MSC y y y
Kathy Chapman Digital Equipment Corporation - - -
Jeff Dalton University of Edinburgh - y y
Jerry Duggan HP - y y
Dick Gabriel Lucid, Inc. - y y
David Gray TI y y y
George Hadden Honeywell Systems \& Research - y y
Gregor Kiczales Xerox PARC - y y
Timothy Koschmann Southern Illinois University y y y
Aaron Larson Honeywell - y y
Thom Linden IBM y y y
David Loeffler MCC - y y
Sandra Loosemore Evans & Sutherland - y y
Barry Margolin Thinking Machines - y y
Larry Masinter Xerox PARC y y y
Bob Mathis Contel - y y
Crispin Perdue Sun Microsystems - y y
Dan Pierson Encore - y y
Kent Pitman Symbolics - y y
Rick Tucker Mitre Corporation - y y
David Unietis Lucid, Inc. - y y
Mary Van Deusen IBM Research y y y
Walter van Roggen Digital Equipment Corporation - y -
Ellen Waldrum TI - y y
JonL White Lucid, Inc. - y y
Jan Zubkoff Lucid, Inc. - y y
∂29-Sep-88 1546 X3J13-mailer Fairfax Subcommittee Meetings Update
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 15:46:06 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00255g; Thu, 29 Sep 88 14:44:00 PST
Received: by challenger id AA00811g; Thu, 29 Sep 88 15:41:40 PDT
Date: Thu, 29 Sep 88 15:41:40 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809292241.AA00811@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax Subcommittee Meetings Update
Subcommittee meetings
October 10, 1988
9:30 - 5:00 Characters (4-5)
9:30 - 12:30 Cleanup (?)
12:30 - 4:30 Editorial
2:00 - 5:00 Compiler (12)
2:30 - 5:00 Iteration (4)
∂29-Sep-88 1544 X3J13-mailer Fairfax Updated Agenda DRAFT
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 15:44:29 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00252g; Thu, 29 Sep 88 14:42:24 PST
Received: by challenger id AA00808g; Thu, 29 Sep 88 15:40:06 PDT
Date: Thu, 29 Sep 88 15:40:06 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809292240.AA00808@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax Updated Agenda DRAFT
**************DRAFT**************
X3J13 Committee Meeting Agenda
October 11 - 12, 1988
1 Call to Order, October 11, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Character Subcommittee Report and Vote, Thom Linden (3 hrs)
6 Lunch, 12:00pm - 1:00pm
7 CLOS Workshop Report, Danny Bobrow (20 minutes)
8 CLOS Chapter 3, Gregor Kiczales (20 minutes)
9 Compiler Subcommittee Report and Vote, Sandra Loosemore (2 hrs)
10 Editorial Subcommittee Report, Kathy Chapman (30 minutes)
11 Recess, 5:00pm
12 Call to Order, October 12, 9:00am
13 Clean-up, Larry Masinter
14 Lunch, 12:00pm - 1:00pm
15 Error Terminology, Dan Pierson (30 minutes)
16 Registry for Packages, Modules, Features, Larry Masinter
17 Public-ftp access, Larry Masinter
18 Other committee reports
19 Adjournment, 5:00pm
∂29-Sep-88 1825 X3J13-mailer Re: Fairfax Updated Agenda DRAFT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Sep 88 18:25:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 SEP 88 18:16:24 PDT
Date: 29 Sep 88 18:16 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Fairfax Updated Agenda DRAFT
In-reply-to: Jan Zubkoff <jlz@lucid.com>'s message of Thu, 29 Sep 88
15:40:06 PDT
To: Jan Zubkoff <jlz@lucid.com>
cc: x3j13@sail.stanford.edu
Message-ID: <880929-181624-1531@Xerox>
The two other topics I wanted to discuss -- registry for packages, modules,
features, and public-ftp access for public Common Lisp programs, I thought
would only take about 30 minutes, mainly just to organize something.
∂30-Sep-88 0956 X3J13-mailer Fairfax attendees
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 30 Sep 88 09:55:45 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 30 Sep 88 12:44:03 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 30 Sep 88 12:52:50 EDT
Date: Fri, 30 Sep 88 12:53 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Fairfax attendees
To: Jan Zubkoff <jlz@lucid.com>
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8809292238.AA00805@challenger>
Message-Id: <19880930165324.8.BARMAR@OCCAM.THINK.COM>
Date: Thu, 29 Sep 88 15:38:54 PDT
From: Jan Zubkoff <jlz@lucid.com>
Thus far:
X3J13 Attendee Information
09/23/88
Name Institute Paid L1 L2
Barry Margolin Thinking Machines - y y
I had our purchasing department send you a check with the registration
form. Did you receive the registration form without a check?
barmar
∂30-Sep-88 1236 X3J13-mailer March '89 X3J13/ISO meeting host needed
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Sep 88 12:36:18 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00792g; Fri, 30 Sep 88 11:34:12 PST
Received: by challenger id AA01696g; Fri, 30 Sep 88 12:31:53 PDT
Date: Fri, 30 Sep 88 12:31:53 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809301931.AA01696@challenger>
To: x3j13@sail.stanford.edu
Subject: March '89 X3J13/ISO meeting host needed
I need a volunteer from the Boston area to host the X3J13 meeting March 27 -
29 and the ISO meeting March 30 - 31. Please let me know if you're
interested.
---jan---
∂30-Sep-88 1405 X3J13-mailer Arpanet access during Fairfax meeting
Received: from hqda-ai.ARPA by SAIL.Stanford.EDU with TCP; 30 Sep 88 14:05:48 PDT
Received: by hqda-ai.ARPA; Fri Sep 30 16:43:12 1988
From: Bill Arbaugh <arbaugh@hqda-ai.ARPA>
Message-Id: <8809302043.AA02302@hqda-ai.ARPA>
To: x3j13@sail.stanford.edu
Date: Fri, 30 Sep 88 16:43:10 EDT
Subject: Arpanet access during Fairfax meeting
X-Mailer: Elm [version 1.5b]
If you do not have a TAC card and would like to have access
to the arpanet for mail and etc., contact me directly and I can
help.
Bill
==========================================================
Bill Arbaugh Phone: (202) 694-6912
UUCP: *!uunet!cos!hqda-ai!arbaugh ARPA: arbaugh@hqda-ai.arpa
==========================================================
∂03-Oct-88 1122 X3J13-mailer Subcommittee Meetings at Contel
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Oct 88 11:22:04 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00587g; Mon, 3 Oct 88 10:19:33 PST
Received: by challenger id AA00351g; Mon, 3 Oct 88 11:15:46 PDT
Date: Mon, 3 Oct 88 11:15:46 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8810031815.AA00351@challenger>
To: x3j13@sail.stanford.edu
Subject: Subcommittee Meetings at Contel
Please note that the subcommittee meetings will be held at Contel. Ask for
Bob Mathis. Security will escort you to the meeting rooms.
---jan---
∂03-Oct-88 1252 X3J13-mailer Error terminology
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Oct 88 12:52:40 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06841; Mon, 3 Oct 88 12:51:06 PDT
Message-Id: <8810031951.AA06841@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 Oct 88 15:42
To: x3j13@sail.stanford.edu
Subject: Error terminology
Following is the proposed error terminology for the forthcoming standard. The
editorial committee has not completely finished shaking the bugs out of this
document, but we thought you might like to comment on it yourselves both
now and at the October meeting. We hope to have consensus on this terminology
in the near future so that it can be used during the writing of phase 2 of
the standard.
Thanks in advance for your review time.
Condition Terminology
September, 1988
Edited by Kathy Chapman, Kent Pitman, Walter Van Roggen
!
Page 2
1 INTRODUCTION
Common Lisp constructs are described in the forthcoming
standard in terms of their behavior in "situations" during which
they are intended to be used (see "Description" and
"Environment/Evaluation" parts of each construct specification),
and in all other "situations" (see "Conditions" part of
specification).
A "situation" is the evaluation of an expression in some
specific context. A "condition", represented by a condition
object, is a situation which has been detected. Some types of
conditions are predefined by the Common Lisp system, and all types
of conditions are subtypes of type CONDITION, i.e. (typep c
'condition) is true if and only if C is a condition. An "error"
is a condition in which normal program execution may not continue
without some form of intervention (either interactively by the
user or under some sort of program control).
"Signalling" is the process by which a situation is announced
by a program and SIGNAL is a mechanism by which such announcement
is done. ERROR and CERROR are also used to signal errors.
Signalling an error has no side-effect on the condition associated
with the error, and there is no dynamic state contained in a
condition object. The interactive interface for signalling is
implementation-dependent.
The process of signalling involves the search for and
invocation of a handler, which is a function of one argument (the
condition) that attempts to deal with the situation. Handlers are
established dynamically using HANDLER-BIND or abstractions built
on HANDLER-BIND such as HANDLER-CASE and IGNORE-ERRORS.
IGNORE-ERRORS is used to inhibit entry to the debugger when all
errors are detected, while HANDLER-CASE is used to perform
specified actions when the specified situations occur. If a
handler is found, it may either handle the situation by performing
some non-local transfer of control or "decline" by failing to
perform a non-local transfer of control. If it declines, other
handlers are sought. If no handler is found and the error was
signalled by ERROR or CERROR, the debugger is entered with no
context change.
The debugger prints the description of the situation
represented by the error being signalled along with contextual
information perhaps including information such as which function
detected the error. The debugger should prefix all lines in a
multiline condition message with the character or indentation used
in the first of the lines of the message. The debugger allows
interactive examination or modification of the state of the
program and restarting from the situation.
The condition object given to the handler is created
explicitly by an operation such as MAKE-CONDITION or implicitly by
an operation such as SIGNAL. The handler is executed in the
dynamic context of the program which has invoked it, except that
!
Page 3
the set of available condition handlers will have been rebound to
the value that was active at the time the condition handler was
made active.
2 TERMINOLOGY
Situations in which errors might, should, or must be
signalled are referred to in the standard. The wording used to
describe such situations is intended to have precise formal
meaning. The following list is a glossary of those meanings.
- A VALID PROGRAM
is a program whose code adheres to the requirements of
conforming code listed as follows:
- Conforming code shall not use any constructions that are
prohibited by the standard.
- Conforming code shall not depend on extensions included in
an implementation.
- Conforming code shall not use any extension included in an
implementation.
- A SAFE SITUATION
is a situation in which interpreted code, or code
compiled with the safest optimization level is run.
- AN UNSAFE SITUATION
is a situation in which code compiled with lower safety
levels is run.
- AN ERROR "IS SIGNALLED"
means that
- If this situation occurs, the error will be signalled, in
both safe and unsafe situations.
- Valid programs may rely on the fact that the error will be
signalled in both safe and unsafe situations.
- Every implementation is required to detect the error in
both safe and unsafe situations.
For example, "an `error is signalled' if UNEXPORT is
given a symbol not accessible in the current package."
!
Page 4
- AN ERROR "SHOULD BE SIGNALLED"
means that
- If this situation occurs, the error will be signalled in
safe situations but may not be signalled in unsafe ones.
- Valid programs may not rely on the fact that the error
will be signalled.
- Every implementation is required to detect the error at
least in safe situations.
- When the error is not signalled, the "consequences are
undefined" (see below).
In summary, the situation which has been identified as an
error is illegal in all implementations, but some
implementations do not actually detect the situation.
For example, "an error `should be signalled' if ENDP is
given a non-list argument."
- THE "CONSEQUENCES ARE UNDEFINED"
means that
- If this situation occurs, the consequences are
unpredictable. The consequences may range from harmless
to fatal.
- Implementations are allowed to detect this situation and
signal an error, but no implementation is required to
detect the situation.
- No valid program may depend on the effects of this
situation, and all valid programs are required to treat
the effects of this situation as unpredictable.
- In places where the words "must", "must not" or "may not"
are used, then "the consequences are undefined" if the
stated requirement is not met, and no specific consequence
is explicitly stated.
There are two principal reasons why this language permits
a situation to have an undefined consequence rather than
requiring an error to be signalled:
- Detecting the situation might be prohibitively expensive
in some or all implementations.
!
Page 5
- An "implementation may be extended" to cover this
situation.
For example, "the `consequences are undefined' is there
is an attempt to redefine the name of a special form."
- THE "RETURN VALUES ARE UNDEFINED"
means that only the number and nature of the return
values of a construct are not well defined but any side-effect
and transfer-of-control behavior is well defined.
For example, if the return values of some function F are
undefined, then an expression such as (length (list (F))) is
still well-defined because it does not rely on any particular
aspect of the value or values returned by F.
- THE "CONSEQUENCES ARE UNSPECIFIED"
means that
- The consequences of this situation are not specified in
the standard, but will not, by themselves, cause execution
to abnormally terminate.
- Implementations are allowed to specify the consequences of
this situation.
- No portable program can depend on the consequences of this
situation, and all portable programs are required to treat
the situation as unpredictable but harmless.
For example, "if the second argument to SHARED-INITIALIZE
specifies a name that does not correspond to any slots
accessible in the instance, the `consequences are
unspecified.'"
- "IMPLEMENTATIONS MAY BE EXTENDED" TO COVER THIS SITUATION
means that an implementation is free to treat the
situation in ANY ONE of the following ways.
1. When the situation occurs, an error is signalled at least
in safe situations,
OR
2. When the situation occurs, the "consequences are
undefined",
OR
!
Page 6
3. When the situation occurs, the consequences are defined
and specified.
Also, no portable program can depend on the consequences
of this situation, and all portable programs are required to
treat the consequences of the situation as undefined.
For example, "`implementations may be extended' to define
other type specifiers to have a corresponding class."
- IMPLEMENTATIONS ARE "FREE TO EXTEND THE SYNTAX"
means that in this situation
- Implementations are allowed to define unambiguous
extensions to the syntax of the construct being described.
- No portable program can depend on this extension, all
portable programs are required to treat the syntax as
meaningless.
The standard may disallow certain extensions while
allowing others.
For example, "no `implementation is free to extend the
syntax' of DEFCLASS."
- A "WARNING IS ISSUED"
means that
- If this situation occurs, a warning is issued, as
described in WARN, in both safe and unsafe situations.
- Valid programs may rely on the fact that a warning will be
issued in both safe and unsafe situations.
- Every implementation is required to detect this situation
in both safe and unsafe situations.
- The presence of a warning will in no way alter the value
returned by the form which caused the situation to occur.
For example, "a `warning is issued' by the compiler if a
declaration specifier is not one of those defined in Chapter 9
of CLtL and has not been declared in a DECLARATION
declaration."
- A "WARNING SHOULD BE ISSUED"
!
Page 7
means that
- If this situation occurs, a warning will be issued at
least in safe situations.
- Valid programs may not rely on the fact that a warning
will be issued.
- Every implementation is required to detect such a
situation at least in safe situations.
- The presence of a warning will in no way alter the value
returned by the form which caused the situation to occur.
For example, "a warning `should be issued' by a compiler
if a variable declared to be ignored is ever referred to or is
also declared special, or if a variable is lexical, never
referred to, and not declared to be ignored." (see Chapter 9,
CLtL)
∂04-Oct-88 1159 X3J13-mailer Hotel reservations for Hawaii
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Oct 88 11:58:04 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01362g; Tue, 4 Oct 88 10:55:36 PST
Received: by challenger id AA03260g; Tue, 4 Oct 88 11:53:17 PDT
Date: Tue, 4 Oct 88 11:53:17 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8810041853.AA03260@challenger>
To: x3j13@sail.stanford.edu
Subject: Hotel reservations for Hawaii
There seems to be a little confusion regarding my last note. I asked for the
dates people would be staying in Hawaii only as a reference point to extend
the time in which the reduced fee would be available. This was not an offer
to make hotel reservations. You should contact the hotel directly if you wish
to make reservations.
808/822-3455 ask for Liz Anne
Cheers!
---jan---
∂04-Oct-88 2041 X3J13-mailer Re: error definitions
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Oct 88 20:41:24 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 OCT 88 19:59:52 PDT
Date: Tue, 4 Oct 88 19:59 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: error definitions
To: Barry Margolin <barmar@Think.COM>, Dick Gabriel
<RPG@SAIL.Stanford.EDU>, chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@SAIL.Stanford.EDU, x3j13@sail.stanford.edu,
DJAHANDARI%TOWNS.DEC@decwrl.dec.com, POPA%TOWNS.DEC@decwrl.dec.com
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <19881003194959.0.BARMAR@OCCAM.THINK.COM>,
<OlxIJ@SAIL.Stanford.EDU>,
<19881003212644.4.BARMAR@OCCAM.THINK.COM>,
<8810031951.AA06841@decwrl.dec.com>,
<km9wo@SAIL.Stanford.EDU>
Message-ID: <19881005025941.6.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: 04 Oct 88 11:01 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I might point out that the CLOS committee didn't come up with this
terminology as a joke or in a fit of stupidity. Nor did we accidentally
forget the CLtL terminology. We designed it deliberately and in full
knowledge that it differed from CLtL terminology. Furthermore, we used
that terminology very carefully in the CLOS document.
Right, and more detail about this to follow.
Date: 03 Oct 88 14:06 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I'm not following the debate on this, but I see the question raised
about what these two phrases mean:
1. ``consequences are undefined''
2. ``implementations may be extended''
This terminology was introduced after a great deal of thought about how
to prevent the so called "number of arguments to IF" bug. We believe
that we have restricted the syntactic extensions that can be made to
CLOS, and that that restriction is important for a variety of reasons.
CLOS is a language which provides a great deal of extensibility, and
given that it is a very important concept to be able to restrict that
in places where it is appropriate.
- THE "CONSEQUENCES ARE UNSPECIFIED"
I am not up to speed on this issue, and I am tired, but I believe it is
important that "THE CONSEQUENCES ARE UNSPECIFIED" must not include
"IMPLEMENTATIONS MAY BE EXTENDED" in any way.
-------
∂06-Oct-88 1249 X3J13-mailer Issue: ERROR-NOT-HANDLED (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 12:49:33 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472004; Thu 6-Oct-88 15:48:14 EDT
Date: Thu, 6 Oct 88 15:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-NOT-HANDLED (Version 1)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <881006154802.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
The following issue will be presented at the upcoming meeting.
We might try to vote on this if people feel it non-controversial
enough, but the "two-week rule" could be invoked to suppress a
vote if someone felt they had inadequate time to consider it.
-----
Issue: ERROR-NOT-HANDLED
References: Interactive Condition Handling (Condition System, Rev 18, p19)
Category: CLARIFICATION/CHANGE
Edit history: 25-Sep-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
For delivery purposes, some implementations will want to leave out
major sections of runtime support in programs that do not require
them. The debugger is one such section.
However, since ERROR may be called implicitly by a number of Common
Lisp built-in functions, and since the condition system as currently
described insists that the interactive debugger be entered if a
condition is unhandled, the interactive debugger must be retained in
a saved image of any program that might signal an error unless the
compiler can prove that the error will never go unhandled. This
may be undesirable in some cases and may cause unnecessary bloating
of the saved image.
Proposal (ERROR-NOT-HANDLED:PERMIT-TERMINATION):
Permit implementors to designate an implementation-specific mechanism
for asking that unhandled errors cause `termination of the running
program' rather than entry into the system's debugger.
Implementations choosing to offer such a facility must clearly define
the nature and scope of such program termination, since the concept
of `program termination' is an ill-defined concept in present-day
Common Lisp.
Even when program termination rather than debugger entry would be
the ultimate effect of an unhandled error, the value of
*DEBUGGER-HOOK* (if non-NIL) must be called to provide programmers
the ability of customized debugging.
All implementations must at least provide the option of a system
debugger for use in program development.
Test Case:
(ERROR "Foo"), if unhandled, must now enter the debugger.
Under this proposal, it might also `terminate program execution'
in implementations which choose to provide such a facility and to
clearly define that concept.
Rationale:
Although technically an incompatible change, we're dealing at
the very edge of what the user can expect from the system. Once
an error is signalled and not handled, we're in the domain of
implementation-dependent effect anyway.
Current Practice:
Probably no one does this yet.
Cost to Implementors:
None. This change is upward compatible with existing implementations.
Cost to Users:
None.
Cost of Non-Adoption:
Saved Lisp images might be forced to be gratuitously larger than
they need to be in some implementations.
Benefits:
Addressing this issue will make Lisp more able to compete with
other languages which permit small saved images to result from
small user programs.
Aesthetics:
No significant impact.
Discussion:
This change was requested by Christian Queinnec of France
(queinnec@inria.inria.fr). Pitman supports the change.
∂06-Oct-88 1317 X3J13-mailer Fairfax Registration
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 13:17:15 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00489g; Thu, 6 Oct 88 13:16:04 PDT
Received: by challenger id AA05749g; Thu, 6 Oct 88 13:12:27 PDT
Date: Thu, 6 Oct 88 13:12:27 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8810062012.AA05749@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax Registration
X3J13 Attendee Information
10/05/88
Name Institute Paid L1 L2
Jim Allard Gensym - y y
Jim Antonisse The MITRE Corporation - y -
Bill Arbaugh U.S. Army AI Center - y y
Kim Barrett USC - - -
Kim Barrett Integrated Inference Machines y y y
David Bartley TI y y y
Paul Beiser HP - y y
Danny Bobrow Xerox y y y
Mary Boelk Johnson Controls - y y
Skona Brittian MSC y y y
Tom Bucken Prime Computer y - -
Kathy Chapman Digital Equipment Corporation - - -
Chris Dabrowski NBS - - -
Jeff Dalton University of Edinburgh - y y
Jerry Duggan HP - y y
Dick Gabriel Lucid, Inc. - y y
David Gray TI y y y
George Hadden Honeywell Systems \& Research - y y
Gregor Kiczales Xerox PARC - y y
Timothy Koschmann Southern Illinois University y y y
Aaron Larson Honeywell - y y
Thom Linden IBM y y y
David Loeffler MCC - y y
Sandra Loosemore University of Utah - y y
Barry Margolin Thinking Machines y y y
Larry Masinter Xerox PARC y y y
Bob Mathis Contel - y y
Tracey Miles Unisys - y y
Crispin Perdue Sun Microsystems - y y
Dan Pierson Encore - y y
Kent Pitman Symbolics y y y
Jeff Rosenking ISI - y y
Rick Tucker Mitre Corporation - y y
Tom Turba Unisys y - y
David Unietis Lucid, Inc. - y y
Mary Van Deusen IBM Research y y y
Walter van Roggen Digital Equipment Corporation - y y
Ellen Waldrum TI - y y
JonL White Lucid, Inc. - y y
Jan Zubkoff Lucid, Inc. - y y
----------------
35 35
∂06-Oct-88 1328 X3J13-mailer Revised DRAFT Agenda
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 13:28:44 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00522g; Thu, 6 Oct 88 13:27:37 PDT
Received: by challenger id AA05784g; Thu, 6 Oct 88 13:24:00 PDT
Date: Thu, 6 Oct 88 13:24:00 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8810062024.AA05784@challenger>
To: x3j13@sail.stanford.edu
Subject: Revised DRAFT Agenda
**************DRAFT**************
X3J13 Committee Meeting Agenda
October 11 - 12, 1988
1 Call to Order, October 11, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
- Report on ISO meeting, Dick Gabriel
- Report on Scheme meeting, David Bartley
3 Approval of Agenda
4 Approval of Minutes
5 Character Subcommittee Report and Vote, Thom Linden (3 hrs)
6 Lunch, 12:00pm - 1:00pm
7 CLOS Workshop Report, Danny Bobrow (20 minutes)
8 CLOS Chapter 3, Gregor Kiczales (20 minutes)
9 Loop, JonL White (20 minutes)
10 Compiler Subcommittee Report and Vote, Sandra Loosemore (2 hrs)
11 Editorial Subcommittee Report, Kathy Chapman (30 minutes)
12 Recess, 5:00pm
13 Call to Order, October 12, 9:00am
14 Clean-up, Larry Masinter
15 Lunch, 12:00pm - 1:00pm
16 Registry for Packages, Modules, Features, Larry Masinter (15 minutes)
17 Public-ftp access, Larry Masinter (15 minutes)
18 Other committee reports
19 Adjournment, 5:00pm
20
!
Next meeting: 1/16 - 1/18 1989 Kauaii Hawaii
∂06-Oct-88 1714 X3J13-mailer X3J13 issues to be emailed: stay tuned for barrage
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 17:14:03 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 17:09:44 PDT
Date: 6 Oct 88 17:09 PDT
From: masinter.pa@Xerox.COM
Subject: X3J13 issues to be emailed: stay tuned for barrage
To: X3J13@Sail.stanford.edu
Message-ID: <881006-170944-1740@Xerox>
We have had a huge barrage of mail on numerous cleanup
issues; a number have come in at the last minute.
Some issues are ready for voting at X3J13; it will be nice
to get as many of these out of the way as possible. Others,
as will be identified, are in draft form and not ready for voting; we'll
cover the issue at the plenary session in any case, since we
need to have all open issues completely resolved by
the January meeting.
I hope to have hardcopy available at the meeting as well.
∂06-Oct-88 1718 X3J13-mailer Issue: ALIST-NIL (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 17:18:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 17:12:44 PDT
Date: 6 Oct 88 17:12 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: ALIST-NIL (Version 4)
To: x3j13@SAIL.Stanford.EDU
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <881006-171244-1747@Xerox>
!
Issue: ALIST-NIL
References: Definition of "a-list" (p279), ASSOC (p280)
Category: CHANGE
Edit history: 20-Jun-88, Version 1 by Pitman
04-Sep-88, Version 2 by Masinter (reflect discussion)
21-Sep-88, Version 3 by Masinter (minor edits)
01-Oct-88, Version 4 by Pitman (remove some bias)
Problem Description:
NIL is permitted to be an element of an a-list but very little of
use can be done with such an element, and the idea can be confusing.
In most situations where an a-list entry is to be removed, it is
done by straightfoward uses like
(SETQ THE-ALIST (REMOVE THE-ENTRY THE-ALIST))
or (SETQ THE-ALIST (DELETE THE-ENTRY THE-ALIST)).
Relatively few situations require the more advanced technique of
(SETF (CAR THE-ALIST-TAIL) NIL)
in order to remove an entry from a list. Usually these situations
involve multiple pointers into different parts of the same a-list,
or very long a-lists where DELETE or REMOVE would take a long time.
Proposal ALIST-NIL:DISALLOW:
Change the definition of an a-list to require all elements to be
real conses. Uses of ASSOC with non-standard a-list would be an error.
Test Case:
(ASSOC 'X '(NIL (X . 3)))
is currently defined to return (X . 3).
Under this proposal, this would be an error.
Rationale:
An a-list is a commonly used data structure that should be easy to
explain. Permitting NIL in an a-list complicates the description
considerably.
This change would make the relationship between FIND (with key of
#'CAR) and ASSOC simpler and easier to explain.
Current Practice:
All valid implementations permit NIL in an a-list.
Cost to Implementors:
Since the proposal is to make this an "is an error" situation, no
implementation would be forced to change.
Cost to Users:
There are two basic ways in which we expect this feature is used
currently.
#1: A user wants a leading NIL on an a-list so that if the list
is empty, there's still be a tail to which cells could be
attached in the future. That is,
(DEFVAR *MY-ALIST* (CONS NIL '()))
so that
...(NCONC *MY-ALIST* (LIST new-cell))...
would always be possible as a side-effect and
...(ASSOC element *MY-ALIST*)...
would always be possible for lookup. It might be argued that
this is more clearly written:
(DEFVAR *MY-TABLE* (CONS NIL '()))
(DEFUN ADD-ENTRY (ENTRY TABLE) (NCONC TABLE (LIST ENTRY)))
(DEFMACRO MY-TABLE-CONTENTS (X) `(CDR ,X))
...(ADD-ENTRY new-cell *MY-TABLE*)...
...(ASSOC element (MY-TABLE-CONTENTS *MY-TABLE*))...
#2: A user might want to splice out an element from an a-list, preserving
the place that the element occupied in the list. In the very rare cases
where this was necessary, one could rewrite:
(DEFUN VOID-FIRST-ENTRY (ALIST) (SETF (CAR ALIST) NIL))
as:
(DEFUN VOID-FIRST-ENTRY (ALIST)
(LET ((ENTRY (CONS NIL NIL)))
(SETF (CAR ENTRY) (GENSYM)) ;or ENTRY or something otherwise unique
(SETF (CAR ALIST) ENTRY)))
This might change the behavior of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF
and RASSOC-IF-NOT depending on the predicate used.
Also, in this case, the user must also consider that whatever is used
as the unique key must be acceptable to ASSOC.
In rare cases where neither of these rewrites were acceptable, the user could
still write his own variant of ASSOC to handle NIL even if the system version
did not.
Cost of Non-Adoption:
The only consequence of non-adoption is the burden of carrying around
the additional complexity in each implementation, in the documentation,
and in teaching. The cost of this burden is likely to be a subjective
matter.
Benefits:
FIND (with a :KEY of #'CAR) and ASSOC (with no key) would be identical.
Aesthetics:
This change would simplify the language.
Discussion:
The description of association lists is currently cluttered by this
unmotivated feature; no strong motivation or widespread use
of the feature has been found.
Some people consider this change gratuitous.
The cleanup committee discussed some interesting optimizations
of ASSOC where the existing situation (special-casing NIL) didn't
actually cost in performance (at least in the special case where
the predicate was EQ or EQL), so performance issues were dismisse
d
as a rationale for this change.
∂06-Oct-88 1752 X3J13-mailer Arpanet access during Dallas PI meeting
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Oct 88 17:52:18 PDT
Received: from DUE-PROCESS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 141274; Thu 6-Oct-88 20:51:07 EDT
Date: Thu, 6 Oct 88 20:51 EDT
From: Carl Hewitt <Hewitt@XX.LCS.MIT.EDU>
Subject: Arpanet access during Dallas PI meeting
To: Bill Arbaugh <arbaugh@hqda-ai.ARPA>
cc: x3j13@sail.stanford.edu, Hewitt@XX.LCS.MIT.EDU
In-Reply-To: <8809302043.AA02302@hqda-ai.ARPA>
Message-ID: <19881007005108.0.HEWITT@DUE-PROCESS.AI.MIT.EDU>
Bill,
I would like to obtain a TAC card.
Thanks,
Carl
∂06-Oct-88 1806 X3J13-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 18:06:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 18:02:04 PDT
Date: 6 Oct 88 18:02 PDT
From: masinter.pa@Xerox.COM
to: x3j13@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
Subject: Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)
Message-ID: <881006-180204-1855@Xerox>
apologies if you got this twice; there was a mailer hiccup here.
!
Issue: ARGUMENTS-UNDERSPECIFIED
References: LOGBITP (p 224), MAKE-DISPATCH-MACRO-CHARACTER (p 363),
MAKE-HASH-TABLE (p 283), MAKE-SEQUENCE (p 249), READ (p 375)
MAKE-STRING (p 302), NTHCDR (p 267), PARSE-INTEGER (p 381),
SET (p 92)
Issue: RANGE-OF-START-END-PARAMETERS.
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
4-Sep-88, version 2 by Masinter
19-Sept-88, Version 3 by Chapman
21-Sep-88, Version 4 by Masinter
Problem Description:
The descriptions of LOGBITP, MAKE-DISPATCH-MACRO-CHARACTER, READ, SET,
MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING, NTHCDR, and PARSE-INTEGER
are not clear about the types of the arguments supplied to these
constructs.
Proposal (ARGUMENTS-UNDERSPECIFIED:SPECIFY)
Clarify that the arguments for the listed constructs are as follows:
Construct Argument Type
LOGBITP index non-negative integer
MAKE-DISPATCH-MACRO-CHARACTER char character
MAKE-HASH-TABLE size non-negative integer
MAKE-SEQUENCE size non-negative integer
MAKE-SEQUENCE type type specifier
MAKE-STRING size non-negative integer
MAKE-STRING initial-element string-char
NTHCDR n non-negative integer
SET-SYNTAX-FROM-CHAR to-char,from-char characters
READ and others eof-value any value
SET value any value
(MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING have additional constraints on
their respective SIZE arguments; for example, MAKE-STRING may detect an error if
SIZE is greater than or equal to ARRAY-DIMENSION-LIMIT. Some additional
restriction on the range of characters which can have syntax in readtables
and are allowable to MAKE-DISPATCH-MACRO-CHARACTER SET-SYNTAX-FROM-CHAR might
be required in some other proposal.)
Rationale:
This clarification allows predictible results to occur when
arguments are supplied to these constructs.
Current Practice:
This proposal seems to be in line with current implementations.
Cost to Implementors:
None, since this is consistent with current practice.
Cost to Users:
None, since this is consistent with current practice.
Benefits:
This clarification will assist users in writing portable code.
Aesthetics:
The standard would be less clean were the allowed ranges of its functions not
specified.
Discussion:
There is a separate cleanup proposal RANGE-OF-START-END-PARAMETERS which
addresses a possible incompatible change. This proposal contains what we
think are non-controversial clarifications.
----- End Forwarded Messages -----
∂06-Oct-88 1921 X3J13-mailer Issue: CONTAGION-ON-NUMERICAL-COMPARISONS (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 19:21:12 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 19:18:51 PDT
Date: 6 Oct 88 19:18 PDT
From: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Subject: Issue: CONTAGION-ON-NUMERICAL-COMPARISONS (version 1)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <881006-191851-1973@Xerox>
!
Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
References: CLtL p.194
Category: CHANGE
Edit history: Version 1, 14-Sep-88, Moon
Problem description:
The numerical contagion rules specified on CLtL p.194 make it impossible
for the numerical comparison functions to be transitive when given
arguments of mixed floating and rational types (see example below).
Proposal (CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE):
Instead of using the same contagion rule both for combining functions
and for comparing functions, make the present rule apply only to
combining functions and add the following rule: When rational and
floating-point numbers are compared by a numerical function, the
function RATIONAL is called to convert the floating-point number to a
rational and then an exact comparison is performed. In the case of
complex numbers (RATIONAL is for some unknown reason only allowed on
reals), the real and imaginary parts are handled individually.
It is of course valid to use a more efficient implementation than
actually calling RATIONAL, as long as the result of the comparison is
the same.
Test Cases/Examples:
(defvar a (/ 10.0 single-float-epsilon))
(= a (1+ (floor a)))
should be NIL, since
(= a (floor a))
is certainly T and
(= (floor a) (1+ (floor a)))
is certainly NIL. However, by the rule of floating-point contagion,
(= a (1+ (floor a)))
is the same as
(= a (float (1+ (floor a)) a))
and the latter form is certainly T.
To understand this example better, it helps to realize that
(= a (+ a 1.0))
is always true, by the definition of single-float-epsilon.
Here is a second example:
(defvar i (floor a))
(<= a (+ i 1)) is T.
(< (+ i 1) (+ i 2)) is T.
(<= (+ i 2) a) is T by CLtL, NIL by this proposal.
Thus CLtL requires
a <= i+1 < i+2 <= a
which ought to imply
a < a
which is absurd.
Rationale:
Transitivity of = and of < are important to many algorithms. What CLtL
says now was probably not intentional, but just the result of thinking
that comparing and combining could be lumped together without really
thinking about it.
Without this change, it is impossible to extend the :TEST argument to
MAKE-HASH-TABLE to allow = or EQUALP, since there could be two table
entries with rational keys that are not =, then GETHASH could be
presented with a floating-point argument that is = to both keys.
Current practice:
Lucid is said to implement the proposal. As far as I know all other
implementations do what CLtL currently says.
Cost to Implementors:
This requires a change in what is likely to be intricate and
implementation-dependent code. However, the total effort should
be small compared to the cost of writing that code originally.
Cost to Users:
This is an incompatible change. It's difficult to know if any users
are depending on the current behavior. It seems likely that most users
would expect the proposed behavior, and may be wondering why their
programs don't quite work when the numbers get large.
Cost of non-adoption:
Comparison functions in Common Lisp will be non-transitive.
Benefits:
Comparison functions in Common Lisp will be transitive.
Esthetics:
Having two rules of floating-point contagion may seem less esthetic,
but I'm certain that having the comparison functions behave in a more
mathematically correct fashion outweighs that esthetically.
Discussion:
Everyone who has expressed an opinion has thought this was the right
thing for years, but we never got around to writing it up as a cleanup
proposal.
----- End Forwarded Messages -----
∂06-Oct-88 2007 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:06:49 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472330; Thu 6-Oct-88 23:05:17 EDT
Date: Thu, 6 Oct 88 23:05 EDT
From: Masinter.PA@Xerox.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Reply-To: CL-Cleanup@SAIL.Stanford.EDU
Subject: Issue: DECLARE-TYPE-FREE (Version 6)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <881006230506.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Version 5, 30-Sep-88, Masinter (cost to implementors)
Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
Problem description:
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
any effect:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
(incf y)
...random algorithm...))
Proposal (DECLARE-TYPE-FREE:ALLOW):
Avoid the phrase "affects only variable bindings". Clarify that a type
declaration means that it is an error for the value of the variable not
to be a member of the declared type, within the scope of the declaration.
Clarify that the above programs are valid, and that this kind of
declaration means the same thing as wrapping a THE form around every
reference to the variable, including modifying references by setq or
setf.
Clarify that if nested type declarations refer to the same variable, then
the value of the variable must be a member of the intersection of the
declared types.
Rationale:
It enables optimizing compilers to make use of the otherwise ignored
type information. Many people have often asked for it, and there is
no strong reason to forbid it.
Current practice:
Lucid implements DECLARE-TYPE-FREE:ALLOW already; but under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
Implementations that might currently warn about such declarations
would have to remove the warning; otherwise, it is valid to ignore
type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
every reference.
Esthetics:
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
language.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
Documentation might want to discuss the style implications of
nested declarations intersecting. The interesting cases are:
- An inner declaration could be a subtype of an outer one.
This is the most useful case and probably the only one to
be encouraged in code written by humans. e.g.,
(locally (declare (type number x))
(locally (declare (type integer x))
...use X as integer...))
- An outer declaration could be a subtype of an inner one.
This is useless but harmless. It might happen as the result
of certain macro situations. e.g.,
(locally (declare (type integer x))
(locally (declare (type number x))
...use X as integer...))
- Two types may only partially overlap. This would presumably
happen only as the result of a macro expansion.
(locally (declare (type fixnum x))
(locally (declare (type (or bit package) x))
...use X as BIT...))
∂06-Oct-88 2058 X3J13-mailer Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:58:09 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 20:12:18 PDT
Date: 6 Oct 88 20:12 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
to: x3J13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
REPLY-TO: Cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <881006-201218-2044@Xerox>
apologies if you get this twice; more mailer problems...
!
Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
References: CLtL page 316
Category: CHANGE
Edit history: 20-Sep-88, Version 1, Peck
21-Sep-88, Version 2, Masinter, minor revisions
Problem description:
Currently, defstruct constructor functions can be either the default
constructor function, with *only* keyword arguments, or it can be a
so-called "By Order of Arguments" constructor function with explicitly
*no* keyword arguments. Other functions in Common Lisp allow a free
mix of required, optional, and keyword arguments.
With the current restriction, it is necessary to hand code a function that
will accept optional and keyword arguments and parse the supplied-p
variables explicitly. Even so, it is not obvious to the casual programmer
how to provide the same semantics as defstruct does with respect to default
values and the defstruct init-forms.
Proposal: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Allow combination of &OPTIONAL, &KEY and &AUX arguments in
constructor forms of defstructs.
The current wording in CLtL (p314):
"In addition, the keywords &optional, &rest, and &aux are recognised
in the argument list. They work in the way you might expect ..."
would be extended accordingly.
Example:
It should be possible to write forms like this:
(defstruct (foo (:constructor CREATE-FOO (a &optional b (c 'sea)
&key (d 2)
&aux e (f 'eff))))
(a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
(create-foo 10) => #S(foo a 10 b 2 c sea d 2 e nil f eff)
(create-foo 10 'bee 'see :d 'dee) => #S(foo a 10 b bee c see d dee e nil f eff)
Rationale:
This is a logical extension of the specification which makes some
programming easier.
Current practice:
Some implementations to signal an error. Envos Medley (Xerox Common Lisp)
implements the proposed behavior.
Cost to Implementors:
The modifications to allow intermixed keywords and optionals in implementations
that don't already are likely simple.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
The current situation is non-intuitive and needless restrictive.
Benefits:
Much easier for users to write the constructor function they want.
Probably implementation code would be reduced, since this would no
longer be an error.
Esthetics:
Minor improvement since it removes a needless restriction.
Discussion:
Possibly references to "By-position", "positional", and "By Order of
Arguments" constructor function might need to be changed to something else in
the standard. (They can still be called BOA-constructors, though, right? :-)
∂06-Oct-88 2057 X3J13-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:57:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 19:30:02 PDT
Date: 6 Oct 88 19:30 PDT
From: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
REPLY-TO: CL-CLEANUP@sail.stanford.edu
Subject: Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
Message-ID: <881006-193002-1990@Xerox>
Issue: DECLARE-FUNCTION-AMBIGUITY
References: CLtL pp 43 (Table 4-1), 158-159
Issue FUNCTION-TYPE (passed X3J13/June 1988)
Category: CHANGE
Edit history: #1, 21 Sept 1988, Walter van Roggen
#2, 29 Sept 1988, Walter van Roggen (renamed; lessened ambiguity)
#3, 30-Sep-88, Masinter
Problem description:
CLtL permits confusing and ambiguous FUNCTION declarations. One can say
(DECLARE (FUNCTION F (VECTOR INTEGER) T))
to indicate that the function binding for F is of a certain type. Yet
one can also say
(DECLARE (FUNCTION X Y Z))
to indicate that the variables X, Y, and Z have values which are functions.
The former is an abbreviation for
(DECLARE (FTYPE (FUNCTION (VECTOR INTEGER) T) F))
The latter is an abbreviation for
(DECLARE (TYPE FUNCTION X Y Z))
The ambiguity arises in a case like
(DECLARE (FUNCTION F NIL STRING))
However, it would be an error to declare the type of the constant NIL to be a
FUNCTION, so technically there is no ambiguity--there is just a peculiar
special case.
Using the same declaration for two completely different purposes can lead
to confusion among people writing or reading such code.
It is now more useful to declare that variables have a value which
is of type FUNCTION, since the type FUNCTION has a more well-specified
meaning.
Proposal (DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION)
The declaration (FUNCTION name argtypes valtypes) is no longer permitted
to be an abbreviation for (FTYPE (FUNCTION argtypes valtypes) name).
The declaration (FUNCTION var1 var2) would just be an abbreviation for
(TYPE FUNCTION var1 var2).
Rationale:
Continuing to allow all the predefined atomic type specifiers as declaration
abbreviations for (TYPE type var1 var2 ...) is simpler for users to understand.
In other words, all the normal type declarations describe variable bindings;
only the FTYPE declaration describes function bindings. This is a more
uniform solution than making an exception to table 4-1.
Since the old use of the FUNCTION declaration for function bindings was just
an abbreviation for the FTYPE declaration, no expressivity is lost.
Furthermore one is able to say that a variable's value is of type FUNCTION,
something that hadn't been clearly possible without using the TYPE declaration.
Current Practice:
Many current implementations treat FUNCTION declarations
only as abbreviations for FTYPE declarations, primarily because
the proposal FUNCTION-TYPE has not been widely implemented.
Cost to Implementors:
Likely to be small to those implementations that heed these kinds of
declarations; none for those that don't.
Cost to Users:
Existing uses of the FUNCTION declaration for function bindings will need
to be changed to FTYPE declarations.
Cost of Non-Adoption:
People will continue to be confused by function declarations.
Benefits:
A simpler language.
Esthetics:
Discussion:
Making it clear that only FTYPE declarations describe function bindings will
make it easier to add new kinds of declarations that support incremental or
additional descriptions, as is needed for describing methods.
Since all cases can be disambiguated after all, compatibility considerations
might deem this proposal to be unnecessary. However, making declarations
simpler and less confusing is possibly more important than compatibility.
There is no consensus on the cleanup committee.
∂06-Oct-88 2058 X3J13-mailer Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:57:57 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 19:40:12 PDT
Date: 6 Oct 88 19:40 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)
To: x3j13@SAIL.STANFORD.EDU
REPLY-TO: CL-CLEANUP@Sail.stanford.edu
line-fold: NO
Message-ID: <881006-194012-2001@Xerox>
!
Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT
References: DECODE-UNIVERSAL-TIME (p445)
Category: CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
30-Sep-88, Version 2 by Masinter
Problem Description:
The description of DECODE-UNIVERSAL-TIME does not say what happens with
TIME-ZONE. Since the description of ENCODE-UNIVERSAL-TIME mentions that
its behavior differs depending on whether a time zone is explicitly passed,
some implementors may have assumed that DECODE-UNIVERSAL-TIME should do
likewise.
Even if all implementations did the same thing, it should still be clarified
whether an implementation were permitted to return dsp=NIL tz=n rather than
dsp=T tz=n+1 for time zones in which daylight savings time was believed to
be (or known to be) in effect. Currently, you cannot tell whether "NIL" for
daylight-savings-time-p means "daylight savings time is in effect" or
just "daylight savings time is not known to not be in effect".
These tools appear to be more portable than they are.
Proposal (DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE):
Specify that, like ENCODE-UNIVERSAL-TIME, DECODE-UNIVERSAL-TIME ignores
daylight savings information if a timezone is explicitly specified.
Rationale:
This makes things consistent with ENCODE-UNIVERSAL-TIME.
Test Case:
;; ### This test case relies on time zone not changing in real
;; ### time, in defiance of warning in note at bottom
;; ### of p445.
(LET* ((HERE (NTH 8 (MULTIPLE-VALUE-LIST (GET-DECODED-TIME)))) ;Time zone
(RECENTLY (GET-UNIVERSAL-TIME))
(A (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY))))
(B (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY HERE)))))
(LIST A B (EQUAL A B)))
Under this proposal, this would return ((T 5) (NIL 5) NIL) in EDT, for example.
Current Practice:
Symbolics Genera, Symbolics Cloe, Lucid 3.0 and Envos Medley seem to
implement this proposal. Some other implementations do not.
Cost to Implementors:
The cost of changing this should be trivial.
Cost to Users:
This feature is already not well-defined since no portable program can rely
on the current behavior, so the cost is small.
Cost of Non-Adoption:
The time primitives are considerably less useful if this point is not
clearly spelled out.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Anything that improves the intelligibility of language primitives improves
language aesthetics.
Discussion:
An alternative would be to specify that, unlike ENCODE-UNIVERSAL-TIME,
DECODE-UNIVERSAL-TIME treats daylight savings information the same
regardless of whether a time zone argument is explicitly or not. This seems
actually to be what was intended originally.
This problem arose while trying to port Macsyma between different
Common Lisp implementations. The cleanup committee does not have
a strong opinion on this matter, as long as the behavior is specified.
∂06-Oct-88 2058 X3J13-mailer Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, version 2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:58:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 20:16:51 PDT
Date: 6 Oct 88 20:16 PDT
From: masinter.pa@Xerox.COM
Subject: Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, version 2
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-201651-2055@Xerox>
!
Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
References: CLtL p. 312-314
Category: CLARIFICATION
Edit History: V1, 5 Aug 1988, Sandra Loosemore
V2, 15 Sep 1988, Sandra Loosemore
Problem Description:
CLtL doesn't make clear whether defstructs that :INCLUDE another
structure type and do not specify a :PRINT-FUNCTION inherit the
:PRINT-FUNCTION of the parent structure type. While it is stated on
page 314 that #S syntax is used if a :PRINT-FUNCTION is not specified,
the language on page 313 indicates that all operations on the parent
type will also work on objects of the child type. Because of the
ambiguity, existing implementations have gone both ways, and users
cannot depend on either #S syntax or the parent type's :PRINT-FUNCTION
being used.
Proposal: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Clarify that defstruct types which :INCLUDE another type but do not
specify an explicit :PRINT-FUNCTION inherit the structure print
function from the :INCLUDE'd type. A print function that uses the
default #S syntax (overriding any print function for the parent type)
can be specified by providing the :PRINT-FUNCTION option without an
argument.
Rationale:
Users typically specify a print function for a structure type because
its slots will contain circular objects or large internal data
structures which are confusing when printed. Any structure type that
:INCLUDEs this type will also contain the same slots; it seems more
reasonable to inherit the parent's print function than to use the
default #S syntax.
Implementations may wish to use something like CLOS' DEFMETHOD to
implement structure printing, and such methods will naturally be
inherited from the :INCLUDE'd type.
Current Practice:
Lucid Common Lisp makes structures inherit print functions, as do both
Symbolics Genera and Cloe. VaxLisp uses #S syntax unless an explicit
:PRINT-FUNCTION is specified.
Cost to implementors:
The changes to non-conforming implementations should be fairly minor
and localized.
Cost to users:
It can't be any worse than the status quo.
Benefits:
An area of ambiguity in the language will be removed.
Discussion:
Pitman and VanRoggen support this proposal.
The original version of the proposal did not provide for a way to
force #S syntax to be used. This functionality was added to the
current version because there seemed to be general agreement that it
would be useful. Other alternatives would be to name the function
that does what the #S printer does, or to provide a function that
returns the #S information as a list (as suggested by Waters) so users
can write their own.
-------
----- End Forwarded Messages -----
∂06-Oct-88 2058 X3J13-mailer Issue: EXPT-RATIO (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:58:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 20:49:35 PDT
Date: 6 Oct 88 20:49 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: EXPT-RATIO (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-204935-2100@Xerox>
!
Issue: EXPT-RATIO
References: CLtL pages 204 and 211
Category: CLARIFICATION
Edit history: Version 1, 4-Oct-88, by Aspinall and Moon
Version 2, 6-Oct-88, Masinter (very minor discussion)
Problem description:
The comment (page 204, 2nd para) that "... an implementation [of expt]
might choose to compute (expt x 3/2) as if it had been written
(sqrt (expt x 3) 2)" disagrees with the principal value definition on
page 211. See the example below for a case where the two disagree. We
believe the principal value definitions are consistent and reasonable,
therefore the implementation comment is wrong.
Proposal (EXPT-RATIO:211):
Clarify that (sqrt (expt x 3) 2) is not equivalent to (expt x 3/2)
and that page 211 rules.
Test Cases/Examples:
(defvar x (exp (/ (* 2 pi #c(0 1)) 3))) ;exp(2.pi.i/3)
(expt x 3) => 1 (except for round-off error)
(sqrt (expt x 3)) => 1 (except for round-off error)
(expt x 3/2) => -1 (except for round-off error)
There can be no question that
(expt x 3) ==> 1
because expt is single-valued with an integer second argument, and
(sqrt 1) ==> 1
definitely follows the principal branch of the square root function.
But (expt x 3/2) is defined as (exp (* (log x) 3/2)) (page 211).
(log x) ==> 2.pi.i/3
according to the definition of the logarithm's branch cuts on page 211
(which really comes down to the branch cuts of phase - page 210), so
(* (log x) 3/2) ==> pi.i
and
exp(pi.i) is -1.
Rationale:
We believe the principal value definitions are consistent and
reasonable, therefore the implementation comment is wrong.
Current practice:
Symbolics Genera 7.3 currently returns the wrong answer, following page
204 rather than page 211. Lucid Common Lisp, and
Envos Medley implement the proposal.
Cost to Implementors:
The obvious code changes in complex expt.
Cost to Users:
None.
Cost of non-adoption:
Self-contradictory language specification.
Benefits:
Users can better predict the branch cuts in expt.
Discussion:
Mathematical Explanation: When the expt function returns a complex result
in CL (Cartesian) form, the phase of the complex number is effectively
canonicalized. Information is lost, and that information is necessary to
specify upon which branch of the sqrt function the final result should lie.
Another way to put it would be that although
sqrt(expt(x,3)) = expt(x,3/2)
where expt and sqrt are the mathematical multi-valued functions, it is not
true that:
pvsqrt(pvexpt(x,3)) = pvexpt(x,3/2)
where pvexpt and pvsqrt denote the principal value versions of those functions.
∂06-Oct-88 2111 X3J13-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 21:11:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 21:08:51 PDT
Date: 6 Oct 88 21:08 PDT
From: masinter.pa@Xerox.COM
Subject: Issue FIXNUM-NON-PORTABLE (Version 3)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-210851-2113@Xerox>
!
Issue: FIXNUM-NON-PORTABLE
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 11-Jul-88 (Sandra Loosemore)
Version 2, 15-Sep-88, Masinter
Version 3, 23-Sep-88, Masinter
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges. The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) remove the type BIGNUM from the language.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable.
However, there is little portable use for the type BIGNUM, and it
is inconsistent with many current implementation techniques.
Current Practice:
Xerox Common Lisp has 17-bit fixnums. Most other Common Lisp
implementations have fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum
size.
Several existing Common Lisp implementations have more than two
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing.
Cost to implementors:
Slight. All implementations we know of already define FIXNUMs to be at
least 16 bits and would only have to remove the BIGNUM type specifier
to be in compliance with the proposal.
Cost to users:
Slight. The removal of the BIGNUM type specifier will affect user code
but it appears to be little-used.
Benefits:
The FIXNUM type specifier would have a portable interpretation.
The language would be less confusing.
Discussion:
Earlier discussion of a related proposal contained several other more controversial
components (adding a constant MAX-INTEGER-LENGTH, allowing
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree on.
It is possible that an implementation have a single representation for all
integers, and no way to identify any efficient range of integers. Those
implementations might need to set MOST-POSITIVE-FIXNUM
and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with
the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.
Other alternatives considered (and not necessarly mutually exclusive
with this proposal):
remove the FIXNUM type specifier entirely, while leaving a way
to query what is the most efficient range of integers
leave the range of FIXNUMs unconstrained and introduce a
SMALL-INTEGER type with a fixed range (but no promises about
efficiency) .
guarantee that the value of the constant ARRAY-TOTAL-SIZE-LIMIT be a
fixnum (for efficient array addressing)
It might be possible to specify the required performance behavior
of FIXNUMs more concretely, e.g., specify that the basic integer operations
use algorithms that are not proportional to the size of the data; it
should be just about as fast to add numbers in the middle of the fixnum
range as it is to add, say, 10 and 11. This might be a useful way to describe
the intent of the FIXNUM range, if not its specification.
∂06-Oct-88 2123 X3J13-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 21:23:24 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 21:20:45 PDT
Date: 6 Oct 88 21:20 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-212045-2149@Xerox>
!
Issue: FORMAT-E-EXPONENT-SIGN
References: CLtL pp. 366, 393
Category: CLARIFICATION
Edit history: Bob Cassels, 13 Sep 88
Masinter, 2-Oct-88 (change issue name)
Related issues: <none>
Problem description:
The result of (format nil "~E" 1.0) is specified in a contradictory way.
The ambiguity is whether a plus sign should be printed in front of
the exponent.
The top of page 393 says, "Next, either a plus or a minus sign is
printed, followed by e digits ... [decimal exponent]"
Later on page 393 we see, "If all of w, d, and e are omitted, then the
effect is ... [like prin1].
Page 366 [presumably where prin1 is defined] doesn't explicitly say that
the plus sign is omitted from the exponent, but all the examples (and
usual practice) indicate that.
So the posssibilities are:
A. "1.0e+0"
B. "1.0e0"
The first reference implies that A is correct, the third reference
implies that B is correct. The second reference implies that A and B
are the same.
Proposal (FORMAT-E-EXPONENT-SIGN:FORCE-SIGN):
Specify that ~E always prints a plus or minus sign in front of the
exponent.
This would cause the language on page 393 of CLtL to to change:
"If all of w, d, and e are omitted, then the effect is to print the
value using ordinary free-format exponential-notation output; PRIN1 uses
a similar format for any non-zero number whose magnitude is less than
10**-3 or greater than or equal to 10**7. The only difference is that
the ~E directive always prints a plus or minus sign in front of the
exponent, while PRIN1 omits the plus sign if the exponent is
non-negative."
Test Case:
(format nil "~E" 1.0) => "1.0e+0"
Rationale:
This proposal makes ~E self-consistent. That is more important than
making ~E consistent with PRIN1.
Current practice:
Symbolics Common Lisp, Ibuki Lisp, and VAX Lisp all print the plus
sign as in the test case above. Apollo DOMAIN Common Lisp (version
2.10) and Xerox Common Lisp produce "1.0", which is wrong because
it includes no exponent at all.
Adoption Cost:
Minimal changes to one printing routine for non-conforming
implementations. (No change to the three implementations mentioned
above.)
Cost of non-adoption:
Minor confusion and possible incompatibility among implementations.
Benefits:
Less confusion, more compatibility.
Conversion Cost:
Minimal. It is doubtful that any user programs depend on this
obscure distinction.
Esthetics:
A matter of opinion.
Discussion:
Fortran ~E format requires a sign before the exponent, since the exponent
mark character may be dropped. Since Common Lisp ~E always prints
the exponent marker, the exponent sign may be dropped in the case
that it would be a plus sign.
∂06-Oct-88 2150 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 21:50:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 21:47:56 PDT
Date: 6 Oct 88 21:48 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-214756-2172@Xerox>
Version 2 was distributed at a previous X3J13 meeting.
!
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p. 27, 47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(incorporate comments from Scott Fahlman & others)
Version 3, 13-Feb-88 Masinter
Version 4, 2-Oct-88 Masinter (update references, discussion)
Related issues: FUNCTION-TYPE-KEY-NAME,
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
REST-LIST-ALLOCATION
Problem description:
The FUNCTION type specifier list is provided to allow declaration of function argument types and return value types. This type specifier uses a syntax similar to the usual lambda list syntax to specify which types go with which lambda list variables. However, this is actually of limited usefulness in the context of a declaration, where one normally wants type information about the actual arguments which can be passed to the function rather than the lambda variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always bound to a value of type LIST. For the sake of consistency, it would seem that the corresponding type given in the FUNCTION declaration must also be LIST, but since this provides no information about the actual arguments, some users/implementors have instead adopted the convention of supplying the type of the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the type specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided with &REST is the type of each actual argument, not the type of the corresponding lambda variable.
Example:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must be LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Most Common Lisp implementations currently ignore FUNCTION type declarations. The only examples found so far are in a text book on Common Lisp, which follows the proposed syntax.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do so. Probably only a small amount of code would have to be written/changed in implementations that currently think that the &REST argument should be LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must be LIST will have to change their code. However, because this issue is so unclear, the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language design.
Esthetics:
Debatable. One the one hand, since the argument type syntax used by the FUNCTION type specifier mirrors normal lambda-list syntax, it would be cleaner and less confusing to provide the type of the lambda variable rather than the type of the actual arguments. However, considering the types specified in the FUNCTION specifier to be the types of the actual arguments rather than the types of the parameters as seen on the receiving end makes the proposed semantics more palatable.
Discussion:
This issue provoked considerable debate in the cleanup committee and at X3J13. It seems like a vote on LIST-TYPE-SPECIFIER would help clarify some of the issues; if there is a LIST type specifier, there would be more support for the alternative proposal to require that the &REST argument declaration, if any, always be LIST or a subtype of LIST, and to extend the LIST type to allow declarations of the form, e.g., (LIST NUMBER).
Those who favor USE-ACTUAL-ARGUMENT-TYPE argue that the simplicity of the declarations and the ugliness of the alternative, as well as the weight of current practice, argue for it.
Kent Pitman has argued against this proposal on the following grounds:
``* It is bothersome that the same argument declarations which are used internally in the function would not be be usable externally.
``* It is unfair to provide only this special-purpose way of declaring a sequence type when in fact there are numerous other places in the language where it might be useful to declare a sequence type.
``If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated explicitly (if it is not already in CLtL somewhere) that the following is illegal:
(DEFUN FOO (&REST X) X)
(APPLY #'FOO T)
since there will be no way to type-declare this. Even though this is an obscure case (that doesn't even work in some implementations), it's the sort of thing that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE.''
∂07-Oct-88 0743 CL-Cleanup-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 07:43:06 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 7 Oct 88 10:42:59 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 7 Oct 88 10:39:56 EDT
Date: Fri, 7 Oct 88 10:40 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue FIXNUM-NON-PORTABLE (Version 3)
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <881006-210851-2113@Xerox>
Message-Id: <19881007144039.0.BARMAR@OCCAM.THINK.COM>
Date: 6 Oct 88 21:08 PDT
From: masinter.pa@xerox.com
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(2) remove the type BIGNUM from the language.
I don't really see the point of this. Isn't BIGNUM simply defined to be
(AND INTEGER (NOT FIXNUM))? I admit that it isn't an extremely useful
type specifier, but it is just as portable as FIXNUM.
barmar
∂07-Oct-88 1501 X3J13-mailer Issue HASH-TABLE-TESTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 15:01:13 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 14:45:57 PDT
Date: 7 Oct 88 14:45 PDT
From: masinter.pa@Xerox.COM
Subject: Issue HASH-TABLE-TESTS (Version 1)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-144557-1115@Xerox>
!
Issue: HASH-TABLE-TESTS
References: CLtL, p382 (third paragraph), and p383
Issue EQUAL-STRUCTURE
Requires Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Category: Addition
Edit history: 26-Sep-88 Version 1 by JonL
Problem Description:
A great many users try to coalesce two equivalent defstruct instances,
or two equivalent pointer arrays, using hash tables; but they are rudely
awakened when they find out that EQUAL is not an appropriate test for
this case, and that there is no :test argument to MAKE-HASH-TABLE which
will "hash on non-tree structures".
Proposal: HASH-TABLE-TESTS:ADD-EQUALP
With the advent of the issue CONTAGION-ON-NUMERICAL-COMPARISONS, we
can expect EQUALP to be a true equivalence function, and thus a suitable
candidate for the :test function to MAKE-HASH-TABLE. Hash-tables will
come in four kinds, the difference being whether the keys are compared
with EQ, EQL, EQUAL, or EQUALP.
Examples:
> (defstruct foo a b c)
FOO
> (setq x (make-foo :a 1 :b 'b :c '(1 . 2))
x-copy (make-foo :a 1 :b 'b :c '(1 . 2)))
#S(FOO A 1 B B C (1 . 2))
> (setq y #(1 B (1 . 2))
y-copy (copy-seq y))
#(1 B (1 . 2))
> (setq ht-equal (make-hash-table :test 'equal)
ht-equalp (make-hash-table :test 'equalp))
#<Hash-Table BB1F7B>
> (progn (setf (gethash x ht-equal) t) (setf (gethash x ht-equalp) t)
(setf (gethash y ht-equal) t) (setf (gethash y ht-equalp) t))
T
> (gethash x-copy ht-equal)
NIL
NIL
> (gethash x-copy ht-equalp)
T
T
> (gethash y-copy ht-equal)
NIL
NIL
> (gethash (copy-seq y) ht-equalp)
T
T
>
Rationale:
Implementing hash-tables efficiently is not an easy task; it makes more
sense for this to be standardly available (implemented by the wizards at
the Lisp vendor companies) than for individual programmers to keep trying
to re-invent this obscure part of technology.
Current Practice:
Lucid's release 3.0 implements this proposal [some 2.1-level release
supported it "provisionally"]. Symbolics implementation is reputed
to be robust enough to implement this proposal trivially.
Cost to Implementors:
Moderate. Implementors have already dealt with EQUAL; the only tricky
part will be ensuring the implication:
"If 'a' is EQUALP to 'b', then 'a' and 'b' must lie in the
same collision chain in any given EQUALP hash table"
It has been suggested that merely linear searching a table is an acceptable
implementation technique for CL's hash-tables [although no serious
implementation limits itself thus] and that such tables have no "collision
chains"; but in fact, this is the degenerate case wherein all entries are
in the same collision chain, so the implication is trivially satisfied.
Some persons prefer to say that the "reprobe sequence will be the same for
the two items", rather than using the term "collision chain"; the meaning
is the same.
Cost to Users:
None. This is an entirely upwards-compatible addition.
Cost of non-adoption:
Continuing bug reports from CL vendors' customers about why "hashing
doesn't work" when said customer tries entering pointer-containing objects
other than cons cells into hash tables. Continuing delay in same
customers work until they figure out a new strategy for identifying
equivalent structures. More difficulty in debugging their alternatives.
Benefits:
Addresses one aspect of the difficult equivalence problem. Makes
hash tables usable with the major, remaining equivalence predicate
of CL. Also as a "side effect", permits case-insensitive hashing
on strings [tables of type EQUAL are case-sensitive on strings];
another "side effect" is the abililty to use the CL numeric comparison
"=" for numbers [tables of type EQUAL use EQL on numbers].
Aesthetics:
Reduces the discontinuity between basic equivalence functions and those
usable as equivalence relations in hash-tables.
Discussion:
With the rejection of all the issues related to EQUAL-STRUCTURE, there is
little or no hope that EQUAL will be "beefed up" to meet the expectations
of so many of the user community on compound structures. If one wants
a hash-table with a :test function that has fewer equivalence classes
(i.e., does more "coalescing"), then there is no alternative now except
to use the function EQUALP.
∂07-Oct-88 1501 X3J13-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 15:01:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 88 14:53:48 PDT
Date: 7 Oct 88 14:53 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-145348-1132@Xerox>
!
Issue: IN-PACKAGE-FUNCTIONALITY
References: IN-PACKAGE (p183)
Category: CHANGE
Edit history: 07-Jul-88, Version 1 by Pitman
7-Oct-88, Version 2 by Masinter (discussion)
Related-Issues: DEFPACKAGE
Problem Description:
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):
Eliminate the ability of IN-PACKAGE to create a package on demand.
Require IN-PACKAGE to signal an error if the package does not exist.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
Clarify that DEFPACKAGE is the preferred way to declare a package,
and MAKE-PACKAGE is the preferred way to construct a package at runtime.
Eliminate the compile-time processing requirement for all package-related
functions except IN-PACKAGE and DEFPACKAGE.
Test Case:
#1: (IN-PACKAGE 'NO-SUCH-PACKAGE) ;signals an error
#2: (DEFPACKAGE FOO ...options...) ;defines/creates a package
(IN-PACKAGE 'FOO) ;selects an existing package
Rationale:
This would greatly improve error checking and modularity, with only minimal
loss of functionality. Any call to IN-PACKAGE which really needed to
demand-create a package could be rewritten as a DEFPACKAGE followed by an
IN-PACKAGE.
Current Practice:
Probably no one implements this behavior since it's in direct
contradiction of both the definitions and numerous examples in CLtL.
Cost to Implementors:
This change would be straightforward to implement.
The cost may not be trivial in all cases, but should not be very large.
Cost to Users:
In most cases, minor syntactic changes to some files would be necessary.
In many cases, no changes would be necessary since files may already be
doing IN-PACKAGE in situations where the author is hoping he's made sure
the real package declaration is already loaded.
Cost of Non-Adoption:
Reduced error checking.
Less modular code.
Benefits:
Errors due to demand-creation of a package by IN-PACKAGE without appropriate
uses of the :USE or :NICKNAMES or without appropriate calls to EXPORT, etc.
afterward would be easier to detect.
Modular package declarations would be encouraged.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether the
package should exist already or not) is clearly not aesthetic. This change
would be an aesthetic improvement.
Discussion:
The cleanup committee supports IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY.
The dual use of IN-PACKAGE has not been helpful and is confusing.
Some members support it only if DEFPACKAGE passes; others would like
to see IN-PACKAGE changed even if DEFPACKAGE were not added to the language.
However, there might be some compilation problems if IN-PACKAGE
changes and MAKE-PACKAGE signals an error if the package exists.
∂07-Oct-88 1643 X3J13-mailer Issue: NTH-VALUE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:43:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 16:38:01 PDT
Date: 7 Oct 88 16:38 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: NTH-VALUE (Version 3)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-163801-1388@Xerox>
Issue: NTH-VALUE
References: Multiple values, pp. 133-139
Category: ADDITION
Edit history: 16-Aug-88, Version 1 by Pierson
01-Oct-88, Version 2 by Pitman (minor edits)
5-Oct-88, Version 3 by Masinter
(add Current Practice as per Gray)
Problem description:
The set of operations on multiple values in Common Lisp is incomplete:
The only ways to retrieve just one of several return values (other than
the first) are:
- Bind several variables and then ignore all but one.
eg, (MULTIPLE-VALUE-BIND (X Y Z) <exp> (DECLARE (IGNORE X Y)) Z)
This is somewhat cumbersome to write and not perspicuous.
- Get a list of all return values and select from that.
eg, (THIRD (MULTIPLE-VALUE-LIST <exp>))
This is somewhat cumbersome, not perspicuous, and creates
needless garbage.
Proposal (NTH-VALUE:ADD):
Add a new macro NTH-VALUE, described as
NTH-VALUE n form [Macro]
Evaluates the FORM and returns the Nth value returned by the form as
a single value. N is 0-based, i.e. the first returned value is
value 0 (for consistency with NTH and NTHCDR). Both N and FORM are
evaluated, in left-to-right order.
Test Cases/Examples:
With this proposal MOD could be defined as:
(DEFUN MOD (NUMBER DIVISOR)
(NTH-VALUE 1 (FLOOR NUMBER DIVISOR)))
The same code would currently be:
(DEFUN MOD (NUMBER DIVISOR)
(MULTIPLE-VALUE-BIND (DIVIDEND REMAINDER)
(FLOOR NUMBER DIVISOR)
(DECLARE (IGNORE DIVIDEND))
REMAINDER))
Rationale:
This corrects the stated problem.
Current practice:
The TI Explorer and LMI Lambda have this feature.
Cost to Implementors:
Writing the macro version is fairly straightforward.
Some will choose to implement compiler hooks so that code written with
NTH-VALUE will be as efficient as possible. This may involve some
additional work, but presumably nothing major.
Cost to Users:
This is an upward-compatible change.
Cost of non-Adoption:
The occassional code where this comes up may be one or more of
clumsier to write, more difficult to read, or less efficient.
(The feature is rarely used in implementations that have it.)
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
While it does add another function to the language it removes
some need for the hairier multiple-value forms.
Discussion:
Pitman proposed this in the very late pre-CLtL days. It was
rejected then because it was too late in the cycle.
There was not strong sentiment for including this feature
in Common Lisp, but no active opposition.
∂07-Oct-88 1642 X3J13-mailer Issue: LAMBDA-FORM (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:42:42 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 16:07:33 PDT
Date: 7 Oct 88 16:07 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: LAMBDA-FORM (Version 3)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-160733-1324@Xerox>
!
Issue: LAMBDA-FORM
References: LAMBDA (p59)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
02-Oct-88, Version 3 by Pitman
Status: For Internal Discussion
Problem Description:
In Scheme, one writes not #'(LAMBDA ...) but just (LAMBDA ...).
Many Common Lisp programmers have asked for this feature.
It can be written by the user, but since it's a commonly asked
for feature, it would make sense for it to be in the standard.
Also, even though the definition is trivial,
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
it is difficult to offer this as an extension because then "portable
code" tries to define it, it will get a redefinition warning because
it will be clobbering the system's predefined definition.
[An implementation could shadow LAMBDA, but that, too, has associated
problems.]
Proposal (LAMBDA-FORM:NEW-MACRO):
Add a LAMBDA macro, which has equivalent effect to:
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
Rationale:
This is an upward-compatible extension which ``codifies current
practice'' in that it makes a commonly defined macro available
as a standard part of the language.
Test Case:
#1: (DEFUN ADDER (N) (LAMBDA (X) (+ X N)))
(FUNCALL (ADDER 5) 3) => 8
#2: (MAPCAR (LAMBDA (X) (+ X 3)) '(1 2 3)) => (4 5 6)
#3: (MACROEXPAND '(LAMBDA (X) (+ X Y)))
=> (FUNCTION (LAMBDA (X) (+ X Y)))
Current Practice:
Symbolics Genera implements NEW-MACRO.
Symbolics Cloe does not offer a LAMBDA macro because users who defined
their own in portable code complained that they were getting redefinition
warnings that CLtL had led them to believe shouldn't happen. [Ironically,
the redefinition warnings always came when they tried to define LAMBDA
in the way it was already defined!]
Cost to Implementors:
The cost is trivial. A portable definition is shown in the
problem description above.
Cost to Users:
None. This change is basically upward compatible.
Cost of Non-Adoption:
There are no really major consequences of non-adoption.
Benefits:
It's been suggested that some people write '(LAMBDA ...) rather than
#'(LAMBDA ...) because it's less ugly, and then run into confusion
later. If they could just write (LAMBDA ...), some that use overly
superficial reasons for the choice of one notation over another might
accidentally select the primitive they should probably really be using.
Aesthetics:
Some people believe that this makes two different ways to get
essentially the same functionality, and so it clutters the language.
On the other hand, there is at least one precedent for having two
operations that do the identical thing -- NOT and NULL. Both have
been retained because they express different intents. In this case,
the intent of #'xxx might be to ``access'' a function by name (the
name of an anoymous function being its lambda expression), and the
intent of (LAMBDA ...) is to ``create'' a function. This distinction
is subtle but may be expressionally interesting to some programmers
in some situations.
Notationally, some people believe strongly that (LAMBDA ...) looks
a lot better than #'(LAMBDA ...). Certainly it takes up fewer
characters, and (LAMBDA ...) is a notable offender in code needing
to be split onto multiple lines, so every little bit probably helps.
Discussion:
Numerous people have suggested this from time to time in the past,
but it's often been amidst a bunch of other more controversial issues.
Pitman wrote up this proposal and supports LAMBDA-FORM:NEW-MACRO.
Technically, CLtL does already permit implementations to predefine a
LAMBDA macro, but most argue that this leeway was accidental. CLtL
says that "all" functions, etc in CLtL must be in the LISP package,
but it does not say "all and only". This oversight leaves enough room
for implementors to add all manner of extra junk in the LISP package.
A separate cleanup item addresses this issue.
An earlier revision of this proposal considered the alternative of
making this a new special form, but most people seemed to prefer the
simpler alternative of just making it a macro for now.
∂07-Oct-88 2151 X3J13-mailer Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:50:40 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 20:55:12 PDT
Date: 7 Oct 88 20:55 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-205512-1714@Xerox>
!
Issue: RANGE-OF-START-AND-END-PARAMETERS
References: COUNT (p257), COUNT-IF (p257), COUNT-IF-NOT (p257),
DELETE (p257), DELETE-DUPLICATES (p254), DELETE-IF (p254),
DELETE-IF-NOT (p254), FILL (p252), FIND (p257), FIND-IF (p257),
FIND-IF-NOT (p257), MAKE-STRING-INPUT-STREAM (p330),
MISMATCH (p257), NSTRING-CAPITALIZE (p304),
NSTRING-DOWNCASE (p304), NSTRING-UPCASE (p304), SUBSTITUTE (p255),
NSUBSTITUTE-IF (p256), NSUBSTITUTE-IF-NOT (p256),
PARSE-INTEGER (p381), PARSE-NAMESTRING (p414), POSITION (p257),
POSITION-IF (p257), POSITION-IF-NOT (p257),
READ-FROM-STRING (p381), REDUCE (p251), REMOVE (p253),
REMOVE-DUPLICATES (p254), REMOVE-IF (p253), REMOVE-IF-NOT (p253),
REPLACE (p252), SEARCH (p258), STRING-CAPITALIZE (p303),
STRING-EQUAL (p301), STRING-DOWNCASE (p303), STRING-GREATERP (p302),
STRING-LESSP (p302), STRING-NOT-EQUAL (p302),
STRING-NOT-GREATERP (p302), STRING-NOT-LESSP (p302),
STRING-UPCASE (p303), STRING/= (p301), STRING< (p301),
STRING<= (p301), STRING= (p300), STRING> (p301), STRING>= (p301),
SUBSEQ (p248), SUBSTITUTE (p255), SUBSTITUTE-IF (p255),
SUBSTITUTE-IF-NOT (p255), WRITE-LINE (p384), WRITE-STRING (p384)
Category: CLARIFICATION
Edit history: 14-Sep-88, Version 1 by Pitman
Problem Description:
CLtL is not always clear about the possible values which the START and END
parameters of built-in Common Lisp can take.
Proposal (RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL):
Clarify that for functions permitting a parameter named START, START1,
or START2 which delimits the beginning point in a sequence to be
considered for some operation, that paremeter must be a non-negative
integer. If the argument is optional or key (as is the case for all
functions referenced above except SUBSEQ), the value will default to
0 if not supplied. It is not permissible to pass NIL as this argument.
Clarify that for functions permitting a parameter named END, END1,
or END2 which delimits the end point in a sequence to be considered
for some operation, that paremeter must be a non-negative integer
indicating a termination point or NIL indicating the last element
in the sequence. If the argument is optional or key (as is the case
for all functions referenced above), the value will default to NIL
if not supplied. Supplying NIL is, therefore, equivalent to not
supplying this argument.
Test Case:
(SEARCH "F" "FOO" :START1 NIL) is an error.
(SEARCH "F" "FOO" :START2 0) is permissible and is equivalent to
(SEARCH "F" "FOO")
(SEARCH "F" "FOO" :END2 NIL) is permissible and is equivalent to
(SEARCH "F" "FOO")
Rationale:
To keep data flow between programs from becoming excessively complicated,
it's a good idea to specify what the default values are so that they can
be passed explicitly rather than requiring an alternate calling sequence
for all possible cases where the value might need to default.
Current Practice:
Symbolics Genera implements the proposed behavior.
Cost to Implementors:
Hopefully most implementations already do this. Those that do not will
probably have to make quite a number of small changes to both the code
for these functions and to any associated compiler optimizers.
Cost to Users:
This change is upward compatible with existing user code. Any program
which did not conform to this proposal was already not portable.
Cost of Non-Adoption:
Subtle gratuitous differences in the handling of these arguments would
continue to be a possibility and a barrier to portability.
Benefits:
The language would be more regular and well-defined.
Aesthetics:
If it makes things clearer, it's an improvement.
Discussion:
Pitman supports RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL.
∂07-Oct-88 2151 X3J13-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:50:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 88 21:16:06 PDT
Date: 7 Oct 88 21:16 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-211606-1727@Xerox>
!
Issue: RETURN-VALUES-UNSPECIFIED
References: CLOSE (p 332), IN-PACKAGE (p 183), RENAME-PACKAGE (p 184),
TRACE (p 440), UNTRACE (p 440), INSPECT (p 442),
SET-SYNTAX-FROM-CHAR (p 361),
LOCALLY (p 156), PROVIDE (p 188), REQUIRE (P 188)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
19-Sept-88, Version 2 by Chapman
6-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter
Problem Description:
The descriptions of CLOSE, IN-PACKAGE, RENAME-PACKAGE, TRACE, UNTRACE,
INSPECT, SET-SYNTAX-FROM-CHAR, LOCALLY, PROVIDE, and REQUIRE
are not clear about the values returned from those constructs.
Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
Clarify that the return values for the listed constructs are as follows:
CLOSE -- the stream argument.
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the
execution of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
TRACE (when called with arguments) -- implementation-dependent.
UNTRACE -- implementation-dependent.
INSPECT -- implementation-dependent.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
surrounded by an implicit PROGN.
PROVIDE -- implementation-dependent.
REQUIRE -- implementation-dependent.
Rationale:
This clarification allows users to know when they can and can not
count on the values returned from these constructs.
Current Practice:
Varies. For example, in Envos Medley, CLOSE returns T, and
set-syntax-from-char returns the "syntax class" of the new character.
Cost to Implementors:
Small.
Benefits:
This clarification will assist users in writing portable code.
Cost to users:
Small; it seems unlikely that there is much code that currently
depends on the return values of these functions; such code isn't
portable.
Aesthetics:
Specified is better than not, when it makes sense.
Discussion:
PROVIDE and REQUIRE are not likely to appear except in the "top level" of
files, and so their return value is possibly moot. There is also some
sentiment for leaving unspecified the values of the debugging/environment
features such as TRACE and UNTRACE, to allow for experimentation and
growth.
∂07-Oct-88 2150 X3J13-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:50:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 19:35:45 PDT
Date: 7 Oct 88 19:35 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: X3J13@SAIL.Stanford.EDU
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-193545-1651@Xerox>
Another proposal to extend this to other pathname components
will probably be submitted, but not in time for this meeting.
!
Issue: PATHNAME-TYPE-UNSPECIFIC
References: Pathnames (pp410-413)
Category: CHANGE
Edit history: 27-Jun-88, Version 1 by Pitman
Problem Description:
CLtL (p412) specifies that the type is ``always a string, NIL,
or :WILD.'' This description is too restrictive to be practical.
In file systems which have no first-class notion of a name/type
distinction, it is possible to make files named "foo." and "foo"
which are distinct. One of these (usually the former) can get a
type of "" but it is not clear how to represent the other. If
NIL is used, merging primitives cannot detect that the field is
filled and should not be merged against.
Proposal (PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN):
Permit :UNSPECIFIC as a value of the type field of a pathname for
operating systems in which it makes sense.
When a pathname is converted to a namestring, NIL and :UNSPECIFIC
both cause the component not to appear in the string.
When merging, however, a NIL value for a component will be replaced
with the default for that component, while :UNSPECIFIC will be left
alone.
Test Case:
For file systems where :UNSPECIFIC makes sense...
(PATHNAME-TYPE (MAKE-PATHNAME :TYPE :UNSPECIFIC)) => :UNSPECIFIC
(PATHNAME-TYPE (MERGE-PATHNAMES (MAKE-PATHNAME :TYPE :UNSPECIFIC)
(MAKE-PATHNAME :TYPE "FOO")))
Rationale:
This is, by necessity, current practice in some implementations
already.
Current Practice:
Symbolics Genera uses a file type of :UNSPECIFIC on Unix and
ITS file systems, for example.
Cost to Implementors:
None. No change to any implementation is forced.
Some implementations which use a non-standard token other than :UNSPECIFIC
to implement this functionality might want to switch to use :UNSPECIFIC so
that portable programs could expect it.
Cost to Users:
Some programs which manipulate pathnames should be updated to expect
:UNSPECIFIC in the type fields in some situations.
Any program which doesn't already expect :UNSPECIFIC is already not really
portable, however, given that some implementations have been forced to
go beyond the standard in order to represent all possible pathnames.
Cost of Non-Adoption:
Some implementations would be unable to both represent all possible pathnames
in a rational way and at the same time to conform to the standard.
Benefits:
Some programs involving pathnames would be more portable.
Aesthetics:
Sweeping a hairy situation under the rug doesn't make it go away.
This change makes things appear less simple, but since in reality
they were less simple, it is effectively a simplification of the
correspondence between the CL model and reality.
Discussion:
Pitman supports PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.
This feature existed in the Colander draft edition of CLtL, but was
removed for the Laser edition. The following text is excerpted from
the Colander edition, p259:
``??? Query: Is :unspecific really needed over and above nil?
``A component of a pathname can also be the keyword
:UNSPECIFIC. This means that the component has been explicitly
determined not to be there, as opposed to be missing. One way
this can occur is with generic pathnames, which refer not to
a file but to a whole family of files. The version, and usually
the type, of a generic pathname are :unspecific. Another way
:unspecific is used to represent components that are not simply
supported by a file system. When a pathname is converted to a
namestring, nil and :unspecific both cause the component not to
appear in the string. When merging, however, a nil value for
a component will be replaced with the default for that
component, while :unspecific will be left alone.''
∂07-Oct-88 2152 X3J13-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:51:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 21:50:05 PDT
Date: 7 Oct 88 21:50 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-215005-1749@Xerox>
!
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Version 3 by Pierson 5/23/88, per comments by Moon
Version 4 by Pierson 5/26/88, clean up
Version 5 by Pierson 6/28/88, simple design per Masinter
Version 6 by Pierson 7/ 5/88, clean up and split issue
Version 7 by Pierson 7/ 8/88, clean up per Pitman
Version 8 by Pierson 7/ 8/88, yet more clean up
Status: Ready for Release?
Problem description:
CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*. This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.
For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*. A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.
Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
A Common Lisp implementation is required to provide the following
initial streams. Each initial stream has a specific purpose as
defined in CLtL. This proposal redefines the initial bindings of
the streams and leaves the rest of the CLtL description unchanged.
*TERMINAL-IO*
*STANDARD-INPUT*
*STANDARD-OUTPUT*
*ERROR-OUTPUT*
*TRACE-OUTPUT*
*QUERY-IO*
*DEBUG-IO*
The initial bindings of these variables are undefined except
that:
1. They are all initially bound to open streams.
2. The streams must support input and/or output as
indicated by the variable name.
3. None of the standard streams (including *TERMINAL-IO*)
may be directed by synonym streams to another of these
stream variables (except *TERMINAL-IO*), whether
directly or by indirection via some composite stream
such as a two way stream with one of the arms being a
synonym stream.
4. Any or all of these streams may be synonyms for the
common implementation dependent stream. For example,
in an interactive Common Lisp invocation running on a
character terminal, all of the streams mentioned here
might be synonym streams (or two-way streams to synonym
streams) to a pair of hidden terminal input/output
streams maintained by the implementation.
The intent of the above rules is to ensure that it is always
safe to bind any of the above variables to another of the
above variables without unduly restricting implementation
flexibility.
Test Cases/Examples:
(PROGN
(PRINT "Output" *STANDARD-OUTPUT*)
(PRINT "Error" *ERROR-OUTPUT*))
In current Common Lisp will write:
------
Output
Error
------
With proposal *might* write:
------
Output
------
and "Error" appears somewhere else.
(LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
...)
In current Common Lisp:
Might cause a circular stream reference if *DEBUG-IO* was
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
With this proposal:
Would be guaranteed not to cause a circular stream reference
unless the initial value of *DEBUG-IO* had been changed to a value
that did not conform the restrictions in this proposal. While no
Common Lisp implementation should do this, a user program might.
(LET ((*STANDARD-INPUT* *TERMINAL-IO*)
(*STANDARD-OUTPUT* *TERMINAL-IO*))
...)
In current Common Lisp:
Might cause a circular stream reference because *TERMINAL-IO* was
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
With this proposal:
Would be guaranteed not to cause a circular stream reference.
Rationale:
This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output.
Current practice:
Lucid binds *TERMINAL-IO* to a special internal stream type. Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output. Symbolics Genera binds *TERMINAL-IO* as appropriate for each
process, usually to a window for interactive applications or to a
stream which will conjure an interaction window on demand for
background tasks.
Cost to Implementors:
All implementations will have to change to some degree but the changes
will probably be simple and localized. All known implementations
already support the underlying streams required to implement this
proposal.
Cost to Users:
User code which depends on the strict binding hierarchy in CLtL may
have to change.
Cost of non-Adoption:
It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.
Benefits:
Implementations will be more able to match their IO behavior to their
environment and their user's expectations.
Aesthetics:
Improved because this area becomes better defined.
Discussion:
Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
*DEBUG-IO*) should fail to work in a non-interactive environment where
nothing like a terminal exists. This proposal fails to address this.
Masinter notes that:
``In many multi-processing multi-window environments,
the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
differs for each process.''
Pierson and Pitman support STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS.
----- End Forwarded Messages -----
∂07-Oct-88 2206 X3J13-mailer STEP-ENVIRONMENT, version 3
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 22:06:27 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 22:03:43 PDT
Date: 7 Oct 88 22:03 PDT
From: masinter.pa@Xerox.COM
Subject: STEP-ENVIRONMENT, version 3
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-220344-1757@Xerox>
!
Issue: STEP-ENVIRONMENT
References: STEP (CLtL p.441)
TIME (CLtL p.441)
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 10-Jun-88, Masinter (add discussion)
Version 3, 20-Jun-88, Loosemore (not a special form)
Problem description:
CLtL does not specify in what lexical environment the form given to STEP
is evaluated. Some people think it's supposed to be evaluated in the
null environment, others think it is supposed to be evaluated in the
current environment, the one in which the STEP form was evaluated.
The same considerations apply to TIME.
Proposal (STEP-ENVIRONMENT:CURRENT):
1. Clarify that STEP and TIME evaluate the form in the current environment.
2. Clarify that calls to both STEP and TIME may be compiled, but that
in the case of STEP, it is acceptable for an implementation to
interactively step through only those parts of the evaluation that are
interpreted.
Test Cases/Examples:
;Assuming X is not a special variable
(setq x 1)
(let ((x 2))
(step (print x)))
This should print and return 2, not 1, when interpreted.
Rationale:
1. It is more useful for the lexical environment to pass transparently
through STEP and TIME than to reset to the null environment.
2. Although STEP is primarily a debugging tool, there is no reason to
prevent it from being compiled correctly.
Current practice:
Vax Lisp behaves as proposed. Symbolics Common Lisp treats STEP as a special
form and does not allow it to be compiled.
Cost to Implementors:
Minimal.
Cost to Users:
None.
Cost of non-adoption:
These debugging tools will continue to have vague specifications.
Benefits:
Slightly more preicse specification of Common Lisp.
Esthetics:
Slightly improved.
Discussion:
There was some discussion of separating this out into two separate
proposals, but it didn't seem useful.
Eric Benson contributed the definition of TIME in Lucid Common Lisp:
(defmacro time (form)
`(time-internal #'(lambda () ,form)))
The function TIME-INTERNAL looks something like:
(defun time-internal (thunk)
(let ((before-time (get-time-state)))
(unwind-protect
(funcall thunk)
(print-time-information before-time (get-time-state)))))
The definition of STEP is similar. This is just to show that it is
easy to get the right lexical environment even though TIME and STEP
are macros.
VaxLisp expands STEP into something like:
(defmacro step (form)
`(let ((*eval-hook* #'step-command-loop))
,form))
∂07-Oct-88 2151 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:51:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 88 21:26:56 PDT
Date: 7 Oct 88 21:26 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <881007-212656-1734@Xerox>
This issue was distributed at the November 1987 meeting.
It was tabled to allow for discussion of function specs.
The only mail comments, which have not been incorporated,
have been:
Instead of generalizing SYMBOL-FUNCTION, add FDEFINITION and leave
SYMBOL-FUNCTION alone.
Do not modify TRACE and UNTRACE. Leave them implementation-dependent.
!
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
Version 3, 4-Nov-87 Moon, small clarifications at KMP's urging
PROBLEM DESCRIPTION:
The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand. It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.
PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS):
Add to Common Lisp the concept of "setf functions". Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function. The name of this setf function
is a list (setf -name-), where -name- is a symbol. The body of this
function is surrounded by an implicit block named -name-.
The functions, macros, special forms, and declarations defined in CLtL
and listed in the References section above need to be enhanced to accept
such lists in addition to symbols as function names, so that setf
functions can be defined and manipulated.
A setf function receives the new value to be stored as its first
argument. Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function, as for any function, is retrieved by
(documentation '(setf foo) 'function).
Examples:
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(funcall #'(setf ,(car form))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a similar feature,
in that they allow setting functions named (SETF reader). We don't
know of any implementation that has precisely the proposed feature.
ADOPTION COST:
The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols. Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.
The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.
This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.
COST OF NON-ADOPTION:
Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System. Some major rethinking of CLOS would be
required.
BENEFITS:
Allow CLOS to be defined without out-of-hand complexity.
Improve usability of SETF.
CONVERSION COST:
None, this is an upward-compatible change.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new
feature, but otherwise they will still work.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
DISCUSSION:
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. This proposal does not attempt to
change that.
There was some concern about introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
However, the CLOS unsuccessfully tried a number of alternatives.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
This proposal is not incompatible with other extensions to function
specifications present in some implementations.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
d) Introduce a new name for SYMBOL-FUNCTION, since it accepts
non-symbols now.
e) Should one allow these extended function names in the car-position
of an expression to be evaluated? The extra complexity didn't seem
justified, instead, an explicit FUNCALL is required.
∂07-Oct-88 2215 X3J13-mailer Issue: STREAM-ACCESS (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 22:15:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 22:11:28 PDT
Date: 7 Oct 88 22:11 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: STREAM-ACCESS (version 1)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-221128-1779@Xerox>
This issue prompted the following comment, which has not been
incorporated:
"The editorial committee should see to it that it's clear that these
types have to do with `structure' rather than `intent' of the resulting
streams. For example, if you broadcast to two string streams, you have a
stream of type BROADCAST-STREAM, not a stream of type STRING-STREAM, etc."
!
Issue: STREAM-ACCESS
References: streams (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 17-Jun-88, version 1 by Walter van Roggen
Problem Description:
There are many components of streams which are specified upon creation
but are not accessible afterwards. Furthermore there is no way in
Common Lisp to determine the type of a stream to see if it has particular
components, or even if it is OPEN.
Proposal: (STREAM-ACCESS:PROVIDE)
Add the following types and functions to the language:
Stream Data Types and Predicates:
BROADCAST-STREAM [Type]
BROADCAST-STREAM-P object [Function]
The predicate is true if the object is of type BROADCAST-STREAM
and is false otherwise. MAKE-BROADCAST-STREAM returns a stream
of type BROADCAST-STREAM.
CONCATENATED-STREAM [Type]
CONCATENATED-STREAM-P object [Function]
The predicate is true if the object is of type CONCATENATED-STREAM
and is false otherwise. MAKE-CONCATENATED-STREAM returns a stream
of type CONCATENATED-STREAM.
ECHO-STREAM [Type]
ECHO-STREAM-P object [Function]
The predicate is true if the object is of type ECHO-STREAM
and is false otherwise. MAKE-ECHO-STREAM returns a stream
of type ECHO-STREAM.
FILE-STREAM [Type]
FILE-STREAM-P object [Function]
The predicate is true if the object is of type FILE-STREAM
and is false otherwise. OPEN returns a stream
of type FILE-STREAM.
STRING-STREAM [Type]
STRING-STREAM-P object [Function]
The predicate is true if the object is of type STRING-STREAM
and is false otherwise. MAKE-STRING-INPUT-STREAM and
MAKE-STRING-OUTPUT-STREAM return a stream of type STRING-STREAM.
SYNONYM-STREAM [Type]
SYNONYM-STREAM-P object [Function]
The predicate is true if the object is of type SYNONYM-STREAM
and is false otherwise. MAKE-SYNONYM-STREAM returns a stream
of type SYNONYM-STREAM.
TWO-WAY-STREAM [Type]
TWO-WAY-STREAM-P object [Function]
The predicate is true if the object is of type TWO-WAY-STREAM
and is false otherwise. MAKE-TWO-WAY-STREAM returns a stream
of type TWO-WAY-STREAM.
Stream Informational Functions:
BROADCAST-STREAM-STREAMS broadcast-stream ==> list of streams
This function returns a list of output streams that constitute
all the streams the broadcast stream is broadcasting to. It is
an error if the argument is not of type BROADCAST-STREAM.
CONCATENATED-STREAM-STREAMS concatenated-stream ==> list of streams
This function returns a list of input streams that constitute
the ordered set of streams the concatenated stream still has to
to read from, starting with the current one it is reading from.
The list may be () if no more streams remain to be read.
It is an error if the argument is not of type CONCATENATED-STREAM.
ECHO-STREAM-INPUT-STREAM echo-stream ==> input-stream
ECHO-STREAM-OUTPUT-STREAM echo-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type ECHO-STREAM.
SYNONYM-STREAM-SYMBOL synonym-stream ==> symbol
This function returns the symbol whose SYMBOL-VALUE the
synonym stream is using. It is
an error if the argument is not of type SYNONYM-STREAM.
TWO-WAY-STREAM-INPUT-STREAM two-way-stream ==> input-stream
TWO-WAY-STREAM-OUTPUT-STREAM two-way-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type TWO-WAY-STREAM.
Predicate:
OPEN-STREAM-P stream
Returns T if a stream is open, NIL if it is closed. It is an error
if the argument is not a stream.
Current Practice:
VAX LISP implements the proposal.
Cost to Implementors:
Most of these should be trivial to implement, since the information
must be present for nearly all types.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
Discussion:
This issue has come up frequently, particularly dealing with SYNONYM-STREAMs.
∂07-Oct-88 2317 X3J13-mailer Issue: SUBTYPEP-TOO-VAGUE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 23:16:57 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 23:15:12 PDT
Date: 7 Oct 88 23:15 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: SUBTYPEP-TOO-VAGUE (Version 4)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-231512-1832@Xerox>
!
Issue: SUBTYPEP-TOO-VAGUE
References: CLtL p. 72-73
Category: CLARIFICATION
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Version 2, 19 Jul 1988 (Sandra Loosemore)
Version 3, 6-Oct-88 (Masinter)
Version 4, 7-Oct-88 (Masinter, per Moon's comments)
Problem Description:
The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined. In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier).
Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship. This makes it difficult to depend on
subtype relationships in portable code.
Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY
A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a
DEFTYPE defined type specifier.
* Clarify that SUBTYPEP will return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, MEMBER. SUBTYPEP will not return a second
value of NIL when both arguments involve only the words in Table 4-1, or
names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
that expand into only those words and/or names.
* SUBTYPEP should signal an error when handed (for either argument)
a type specifier that involves VALUES or the list form of the FUNCTION
type.
* SUBTYPEP must always return values T T in the case where the two
type specifiers (or their expansions) are EQUAL.
* Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation. For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).
Rationale:
Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
programs cannot rely on any more than NIL NIL as return values.
It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
MEMBER, AND, OR, and NOT are messy to deal with.
Current Practice:
The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE and does not recognize
EQUAL type specifiers as being equivalent. Most other implementations
appear to be substantially in conformance with the proposal.
Cost to implementors:
Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
Cost to users:
Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.
Benefits:
An area of confusion in the language is cleared up. Usages of SUBTYPEP
will be more portable.
Discussion:
The handling of FLOAT and SINGLE-FLOAT appeared to be the
consensus from a discussion on the common-lisp mailing list some
time ago.
It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes
cumbersome.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
The rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail.
∂07-Oct-88 2334 X3J13-mailer Issue: TAGBODY-CONTENTS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 23:34:50 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 23:33:05 PDT
Date: 7 Oct 88 23:33 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: TAGBODY-CONTENTS (Version 4)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-233305-1841@Xerox>
!
Issue: TAGBODY-CONTENTS
References: TAGBODY (pp 130-131 of CLtL)
Category: CLARIFICATION
Edit History: 13-Sep-88, version 1 by Walter van Roggen
02-Oct-88, version 2 by Pitman
(beef up rationale, clarify tag NIL is ok)
04-Oct-88, version 3 by Pitman (fix wording bug)
05-Oct-88, version 4 by Pitman
(modify proposal based on comments from Peck@Sun
-- allow both (GO NIL) and unused duplicated tags)
Problem Description:
CLtL specifies that symbols and integers are valid tags
in a TAGBODY and that lists are valid forms in a TAGBODY
but is silent about other data types.
Also, NIL is both a symbol and a list. Some implementations
might permit (GO NIL) because they treat NIL as a tag,
while others might not permit because they treat NIL as a form.
Proposal (TAGBODY-CONTENTS:FORBID-EXTENSION):
TAGBODY treats symbols (including NIL) and integers as tags,
and treats conses as forms.
It is an error if an expression in a TAGBODY is not a symbol,
an integer, or a cons. Implementations are forbidden from
extending this syntax.
It is an error to do a GO to a tag name for which the same
(i.e., EQL) tag appears more than once in the body of the
innermost TAGBODY containing that tag.
The same restrictions apply to all forms which implicitly use
TAGBODY, such as PROG and DO.
Rationale:
The proposed set of tags is expressionally adequate.
Other obvious candidate types have lurking problems that could
lead to subtle program bugs if permitted as tags. For example,
- Characters make bad tags because, for example,
(TAGBODY ... #\Return ... #\Newline ...)
will be an error in some implementations due to
(EQL #\Return #\Newline).
- Floats make bad tags because round-off error will vary
between implementations.
- Rationals have problems with reduction to lowest terms.
eg, (EQL 1/2 2/4). This doesn't vary between implementations
but may still cause surprises.
Duplicated tags are permitted in situations where no GO is done
to them primarily for two reasons:
- To permit NIL to occur more than once in common situations
such as:
(defmacro foo1 (&rest args)
`(do () ((test-fn))
,(when (member :bar args) '(do-bar-thing))
,(when (member :baz args) '(do-baz-things))
(do-regular-things)))
- To permit the use of symbols as `dividers' between major
sections of code. eg,
(do (...)
(...)
-----
(...)
(...)
-----
(...))
It is not our intent particularly to encourage either of these
practices. Both are easy to work around. But current practice is
to permit such uses in many implementations, and there was no driving
reason to force such code to break.
Current Practice:
Symbolics Genera documents that only symbols or integers are permitted.
The restriction is enforced by the compiler, but not the interpreter.
The TI Explorer permits using NIL as a GO tag, but as a special case,
does not warn about multiple appearances of NIL.
Cost to Implementors:
A few simple checks are probably all that's needed. Probably most
implementations (both interpreters and compilers) already perform them.
Cost to Users:
Unlikely to affect any portable code.
If there are implementations which support other objects as tags
(floats, for example), there may be simple editing necessary.
Benefits:
One less place for portability problems to occur.
Aesthetics:
Makes the language description more precise.
Discussion:
This first appeared in ">GLS>clarifications.text" of 12/06/85.
Historical Note (JonL, Steele):
The reason pdp10 MacLisp allowed numbers, including flonums,
as tags was that Ira Goldstein's LLOGO (a LOGO system
written entirely in Lisp) just used READ for the statement
numbers, and they looked like floats; e.g., 1.1, 1.2, ... etc.
Pitman supports this proposal.
----- End Forwarded Messages -----
∂07-Oct-88 2343 X3J13-mailer Issue: VARIABLE-LIST-ASYMMETRY (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 23:43:45 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 23:41:38 PDT
Date: 7 Oct 88 23:41 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: VARIABLE-LIST-ASYMMETRY (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-234138-1843@Xerox>
The only comment on this issue is that it should include
COMPILER-LET.
!
Issue: VARIABLE-LIST-ASYMMETRY
References: CLtL pgs. 110, 122, 131
Category: ADDITION
Edit history: Revision 1 by Skona Brittain 07/26/88
Revision 2 by Skona Brittain 08/04/88
Problem Description:
The syntax of items in the variable-list for various control structues
(do, let, prog and their duals) varies. This variation seems unnecessary.
The allowed variations are indicated in the following chart:
do & do*: (var) (var init) (var init step)
prog & prog*: var (var) (var init) n.a.
let & let*: var (var val) n.a.
Note that just plain `` var '' is prohibited in do forms
and that the case of ``(var)'' is prohibited in let forms.
Proposal (VARIABLE-LIST-ASYMMETRY:SYMMETRIZE):
Allow all the variations in all of the forms;
i.e. add the prohibited cases mentioned above.
I.e. change the variable-list in the syntax descriptions as follows:
do & do*: ( { var | (var [init [step]] ) }* )
let & let*: ( { var | (var [value] ) }* )
Test Cases:
(let (a (b) (c 3)) ... ) would be valid.
(do* (a (b) (c 3)) ... ) would be valid.
Rationale:
The asymmetry is unnecessary and impedes learning of CL.
Any other way to make these cases consistent, such as either
omitting just ``var'' from do & do* and prog & prog*, or
omitting ``(var)'' from let & let* and prog & prog*,
would be an incompatible change to the language.
This way just adds the flexibility found in some of the forms to all of them.
Current Practice:
KCL allows ``(var)'' in let & let* but not ``var'' in do & do*.
Symbolics Genera allows all three cases in all the forms; i.e. it conforms
to this proposal.
Cost to Implementors:
Extremely slight. (May involve subtracting code rather than adding it).
Cost to Users:
None.
Cost of Non-Adoption:
The variation in syntax makes them harder to learn.
Benefits:
Ease of learning.
Aesthetics:
Symmetry is more aesthetic than asymmetry, at least to some of us.
Discussion:
Kent supports this proposal.
The issue about whether the atomic ``var'' should be allowed at all in the
variable lists for let & let* is a separate issue. (So is whether
it should mean that the var is initially bound to nil.) Since it is allowed,
this proposal merely says that the alternative syntax of an atom within a
list with no initial value, ``(var)'', should also be allowed.
∂08-Oct-88 1150 CL-Cleanup-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 11:49:54 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Sat, 8 Oct 88 14:47:13 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Sat, 8 Oct 88 14:46:39 EDT
Date: Sat, 8 Oct 88 14:47 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <881007-211606-1727@Xerox>
Message-Id: <19881008184726.3.BARMAR@OCCAM.THINK.COM>
Date: 7 Oct 88 21:16 PDT
From: masinter.pa@xerox.com
Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
Clarify that the return values for the listed constructs are as follows:
CLOSE -- the stream argument.
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the
execution of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
surrounded by an implicit PROGN.
Cost to Implementors:
Small.
Benefits:
This clarification will assist users in writing portable code.
Except for LOCALLY, I don't see the point of specifying the return
values of the above functions. Yes, the cost to implementors is small,
but why bother in the first place? I think they should be made
explicitly implementation defined, like the other functions that were
listed.
If others do prefer to specify explicit return values, I agree with the
particular choices (although for SET-SYNTAX-FROM-CHAR I don't see why it
shouldn't return one of the characters).
barmar
∂08-Oct-88 1229 X3J13-mailer REPLY-TO: CL-CLEANUP@Sail.Stanford.Edu
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 12:28:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 12:17:28 PDT
Date: 8 Oct 88 12:17 PDT
From: masinter.pa@Xerox.COM
Subject: REPLY-TO: CL-CLEANUP@Sail.Stanford.Edu
To: Barry Margolin <barmar@Think.COM>
cc: x3j13@sail.stanford.edu
Message-ID: <881008-121728-2116@Xerox>
Barry:
I carefully typed the REPLY-TO: CL-CLEANUP@Sail.Stanford.Edu in all of the
mail to X3J13 with the idea that, if there was discussion on any of these
issues, we should handle them within cleanup. For many of the issues, there
has been a significant amount of prior discussion. We've tried for most of
the issues to at least summarize the discussion, but perhaps we've been
amiss, or have missed some points. You're welcome to participate directly
in the cleanup committee, of course.
I promise all of you that if you send comments on issues to cl-cleanup that
they will not be ignored, and that I think it is important that you are
satisfied that your concerns have at least been aired before a proposal is
voted on in the full X3J13 meeting.
Thanks,
Larry
∂08-Oct-88 1253 X3J13-mailer DRAFT Issue: CLOSED-STREAM-OPERATIONS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 12:53:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 12:48:03 PDT
Date: 8 Oct 88 12:48 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: CLOSED-STREAM-OPERATIONS (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-124803-2142@Xerox>
This issue is in discussion in the cleanup committee. The proposal is not ready for voting at X3J13. This is to inform you about the current state of discussion.
!
Status: DRAFT
Issue: CLOSED-STREAM-OPERATIONS
References: CLOSE (p 332)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
8-Oct-88, Version 2 by Masinter
Related Issues: STREAM-CAPABILITIES, STREAM-ACCESS, STREAM-INFO
Problem Description:
The description of CLOSE is not completely clear about the functions
which are allowed to be performed on a closed stream.
On p332 it says:
"The stream is closed. No further Input/output operations may be
performed on it. However, certain inquiry operations may still
be performed, ..."
but the list of inquiry operations is not specified.
At least one implementation interpreted the list to include
at least OUTPUT-STREAM-P, while another has disallowed that operation
to be performed on a closed stream.
Proposal (CLOSED-STREAM-FUNCTIONS:DISALLOW-ALL)
Clarify that it is an error to perform any operation on a closed stream.
Rationale:
This clarification allows existing implementations to maintain the status
quo, while alerting users to the fact that the result of performing
an operation on a closed stream is undefined in the standard.
Also, the descriptions of OUTPUT-STREAM-P and INPUT-STREAM-P indicate
that these functions can only be performed on streams that have not
been closed.
Current Practice:
At least two implementations differ in which functions are allowed to be
performed on a closed stream.
Adoption Cost:
None.
Benefits:
This clarification will assist users in writing portable code.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Closing streams is necessary for deallocation of system resources that might have been associated with their opening. Implementations and stream-types differ as to how much of the "stream information" that Lisp normally expects to be able to obtain is in the host operating system (and thus deallocated when the stream is closed) and how much is in Lisp, and presumably managed by the normal Lisp storage manager.
Closing a file stream also has the effect of allowing the file to be accessed for other operations in operating systems that implement file interlocking.
Of STREAMP, INPUT-STREAM-P, OUTPUT-STREAM-P, TRUENAME, PATHNAME, which are legitimate on closed streams?
all?
What are the effects of CLOSE on composite streams (such as broadcast, two-way, and concatinated streams?)
close constituents?
What are the effects of CLOSE on a constructed stream (e.g., WITH-OUTPUT-TO-STRING)?
no effect?
∂08-Oct-88 1320 X3J13-mailer DRAFT Issue: COERCE-INCOMPLETE (Version 1)+
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 13:19:52 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 13:09:12 PDT
Date: 8 Oct 88 13:09 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: COERCE-INCOMPLETE (Version 1)+
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-130912-2162@Xerox>
This issue is still under debate and the writeup below is very rough. We think that TYPE-OF-UDERSPECIFIED might help make the issue clearer.
We do not expect to discuss this issue in the full X3J13 session. This is just for your information that we're discussing the topic.
!
Status: DRAFT
Issue: COERCE-INCOMPLETE
Reference: coerce (CLtL p50)
Category: change
Edit history: version 1 by M.Ida, 26-Feb-1988
Problem Description:
--------------------
Problem 1:
Coerce is not symmetric or not generic among data types.
In CLtL, Coerce is defined in page 50 and 51 that,
1) a sequence type may be converted to any other sequence type.
2)Some strings, symbols, and integers may be converted to characters.
2-1) If object is a string of length 1,
then the sole element of the string is returned.
2-2) If object is a symbol whose print name is of length 1,
then the sole element of the print name is returned.
2-3) If object is an integer n,
then (int-char n) is returned.
3) any non-complex number can be converted to a XXX-float.
4) any number can be converted to a complex number.
The next table shows that how coerce is not symmetric among character,
string, symbol and integer.
TABLE 1. Possible Conversions among character, string,symbol, integer
type of conversion provided functions coercion under the CLtL
character -> string string X
character <- string coerce (if the string has only one char.) O
character -> symbol (intern (string @i[ch])) X
character <- symbol coerce (if pname length is 1) O
character -> integer char-code, char-int X
character <- integer code-char (zero font-, zero bits- attrib.) O
int-char (any font- and any bits-)
string -> symbol intern, make-symbol X
string <- symbol string, symbol-name X
string -> integer (char-code (coerce @i[string] 'character)) X
string <- integer (string (code-char @i[integer])) X
symbol -> integer (char-code (coerce @i[symbol] 'character)) X
symbol <- integer (intern (string (code-char @i[integer]))) X
Problem 2:
The function of coerce for character is defined to act as char-int/int-char
not as char-code/code-char.
Proposal: Coerce :replace
-------------------------
COERCE should be more generalized for string, symbol, integer, and character
data types. The observations show there are
no problem if extensions are fully written out in the details.
Here is an extension to the current coerce definition using the CLOS.
(defmethod coerce ((x character) (y (eql string))) (string x))
(defmethod coerce ((x character) (y (eql symbol))) (intern (string x)))
(defmethod coerce ((x character) (y (eql integer))) (char-code x))
(defmethod coerce ((x string) (y (eql symbol))) (intern x))
(defmethod coerce ((x symbol) (y (eql string))) (string x))
(defmethod coerce ((x string) (y (eql integer)))
(char-code (coerce x 'character)))
(defmethod coerce ((x integer) (y (eql string))) (string (code-char x)))
(defmethod coerce ((x symbol) (y (eql integer)))
(char-code (coerce x 'character)))
(defmethod coerce ((x integer) (y (eql symbol)))
(intern (sting (code-char x))))
(defmethod coerce ((x integer) (y (eql character)))
(code-char x)) ; redefinition. CLtL defines as int-char
The keys are
a) ignore char-bits and char-font upon the conversion of characters,
assuming font-attribute will be flushed from the language spec.
b) ignore the package name upon the conversion of symbols.
(package name has no role upon the conversion.)
c) the created symbol will be interned to the current package.
Rationale:
----------
By extending the definition as this document suggests, the functionality
of coerce is symmetric among characters, strings, symbols and integers.
Current Practice:
Cost to implementors:
Cost to users:
Benefits:
Aesthetics:
Discussion:
<<discussion from original Common Lisp design.>>
Making COERCE symmetric would probably be a bad idea, e.g., that it can coerce
from INTEGER to FLOAT and not from FLOAT to INTEGER is on purpose.
We think COERCE from integer to character is odd and non-portable and think it
perhaps should be removed from the standard.
COERCE from character to STRING is a good idea.
We are now puzzled by the inconsistency of (COERCE x 'STRING) vs (STRING x) and
want to reduce it.
We would like (COERCE x 'PATHNAME) to work like (PATHNAME x).
The reason that (COERCE symbol 'STRING) is difficult is that (COERCE 'NIL
'STRING) as a symbol could return "NIL", but (COERCE '() 'STRING) as the empty
list could return "".
FUNCTION-TYPE has extended COERCE to work for 'FUNCTION.
(COERCE "5" 'INTEGER)
should return integer.
!
Issue: COERCE-FROM-TYPE
References: COERCE (p51)
Related-Issues: COERCE-INCOMPLETE
Category: ADDITION
Edit history: 20-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
COERCE is difficult to extend because ambiguities arise about the
source type of the coercion.
For example, should (COERCE NIL 'STRING) return "" or "NIL".
The choice would be arbitrary unless you knew whether NIL was being
viewed as an empty list or a symbol.
Similarly, (COERCE (CHAR-CODE #\A) 'STRING) might return the same
as (FORMAT NIL "~D" (CHAR-CODE #\A)) -- "65" in most ASCII-based
implementations -- or it might return "A", depending on whether the
result of char-code was viewed as a number or more specifically as
a character code.
Proposal (COERCE-FROM-TYPE:NEW-ARGUMENT):
Add an extra optional argument to COERCE which specifies the type
from which the coercion is to be done. The new syntax would be:
COERCE object to &optional (from (TYPE-OF object))
Constrain that FROM must be such that (TYPEP OBJECT FROM) is true.
Rationale:
This leaves room for a subsequent proposal to extend COERCE in
interesting ways. For example, extensions such as the following
might be considered:
(COERCE NIL 'STRING 'LIST) => ""
(COERCE NIL 'STRING 'SYMBOL) => "NIL"
A new type CHAR-CODE might even be introduced as
(DEFTYPE CHAR-CODE () `(INTEGER 0 (,CHAR-BITS-LIMIT)))
so that COERCE could handle cases like:
(EQUAL (COERCE (CHAR-CODE #\A) 'STRING 'NUMBER)
(FORMAT NIL "~D" (CHAR-CODE #\A))) => T
(COERCE (CHAR-CODE #\A) 'STRING 'CHAR-CODE) => "A"
Such specific proposals are deliberately not part of this proposal
in order to separate the general purpose mechanism from the more
specific details.
Current Practice:
Probably no one implements the proposed behavior at this time.
Cost to Implementors:
The more optimization a compiler does (or might do) of COERCE, the more
work might be necessary. In general, however, the changes would probably
not involve a major amount of work.
Cost to Users:
This change is upward compatible.
Cost of Non-Adoption:
Various proposals to extend COERCE would probably not pass because
not everyone can agree on how to view the type of the first argument.
!
M.Ida responds
My primary points are on the relation to CLOS and the simplicity which
might be obtained as a result of the integration.
I further thought that coerce can be viewed as a generic function
(I know recent talk of the mailing list for this).
So I thought it is possible to define for the ambiguous cases
consulting type hierarchy related things in CLOS.
For the above example, since CLOS defines the class precedence list for NULL
as (null symbol list sequence t),
(coerce nil 'string) should be "NIL" first if there are no special methods.
I had thought that COERCE should grow up into a kind of universal function.
But I realized that the current role of COERCE seems to be a very low level primitive.
Possibilities:
extend coerce to handle more types?
Add an extra argument?
Make COERCE generic?
Make COERCE take classes as well as type names?
∂08-Oct-88 1329 X3J13-mailer DRAFT Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 13:29:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 13:25:27 PDT
Date: 8 Oct 88 13:25 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)
To: x3J13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-132527-2172@Xerox>
There have been last-minute edits to the wording (but not the intent) of this issue/proposal that cause me to write DRAFT in the issue status.
!
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
References: Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291
The type-specifiers ARRAY, COMPLEX, SIMPLE-ARRAY, and VECTOR
Related Issues: SUBTYPEP-TOO-VAGUE, LIST-TYPE-SPECIFIER
Category: CHANGE
Edit history: Version 1, 13-May-88, JonL
Version 2, 23-May-88, JonL
(typo fixes, comments from moon, rearrange some discussion)
Version 3, 02-Jun-88, JonL
(flush alternate proposal ["flush-upgrading"]; consequently,
move more of discussion back to discussion section.
Version 4, 01-Oct-88, Jan Pedersen & JonL
(reduce discussion, and "cleanup" wordings)
(Version 5 edit history missing)
Version 6, 6-Oct-88, Moon
(fix typos, cover subtypep explicitly, add complex,
change name of UPGRADE-ARRAY-ELEMENT-TYPE)
Version 7, 7-Oct-88, JonL (more name and wording changes)
Version 8, 8-Oct-88, Masinter (wording, discussion)
Problem description:
CLtL occasionally draws a distinction between type-specifiers "for
declaration" and "for discrimination". Many people are confused by
this situation. A consequence of this distinction is that a variable
declared to be of type <certain-type> and all of whose assigned objects
are created in accordance with that type, may still have none of its
values ever satisfy the TYPEP predicate with that type-specifier.
One type-specifier with this property is
(ARRAY <element-type>)
for various implementation dependent values of <element-type>. For
example, in most implementations of CL, an array X created with an
element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
(TYPEP X '(ARRAY T))
but (almost) never will it satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 5))).
Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
Summary of changes:
Eliminate the distinction between type-specifiers "for declaration" and
"for discrimination". Change the meaning of the <element-type> in the
ARRAY type-specifier and its subtypes, and in the COMPLEX type-specifier,
to be the same for TYPEP and SUBTYPEP as for TYPE declarations.
Specify how SUBTYPEP behaves on these type-specifiers. Add a function
to provide access to the implementation-dependent set of array types
and another function to provide access to the implementation-dependent
set of complex number types.
Specifics:
1. Eliminate references to the distinction between types "for declaration"
and "for discrimination" in the discussion of array and complex
type-specifiers. This would include documentation patterned after CLtL:
a.) The discussion in section 4.5, pp. 45-7
b.) p. 291, the sentence begining "This set may be larger than the set
requested when the array was created; for example . . ."
Instead, (ARRAY <type>) always means all arrays that can result by specifying
<type> as the :ELEMENT-TYPE argument to the function MAKE-ARRAY, and
(COMPLEX <type>) always means all complex numbers that can result by
giving numbers of type <type> to the function COMPLEX, plus all other
complex numbers of the same specialized representation.
2. Change the meaning of (TYPEP <x> '(ARRAY <type>)) to be true if and
only if <x> is an array of the most specialized representation capable
of holding elements of type <type>. In other words, it is true if and
only if <x> is an array and (ARRAY-ELEMENT-TYPE <x>) is type-equivalent
to (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE <type>)).
Do the same for SIMPLE-ARRAY and VECTOR.
3. Change the meaning of (TYPEP <x> '(COMPLEX <type>)) to be true if
and only if <x> is a complex number of the most specialized
representation capable of holding parts of type <type>, or if <x> is of
any subtype of that representation. Both the real and imaginary parts
must satisy (TYPEP <real-or-imag-part> '<type>).
4. Define that for all type-specifiers <type1> and <type2>, other than *,
(ARRAY <type1>) and (ARRAY <type2>) are either equivalent or disjoint,
depending on whether they use the same specialized representation or
distinct representations. This defines the behavior of SUBTYPEP.
5. Define that for all type-specifiers <type1> and <type2>, other than *,
(SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>)) is T T if they use the
same specialized representation, T T if they use distinct specialized
representations but (SUBTYPEP '<type1> '<type2>) is true, and NIL T
otherwise.
6. Require that the resultant ARRAY-ELEMENT-TYPE from a call to
MAKE-ARRAY is independent of any argument to MAKE-ARRAY except for the
:ELEMENT-TYPE argument. Thus the set of specialized array
representations must be consistent between single-dimensional and
multi-dimensional, simple and non-simple, short and long arrays.
7. Add the function IMPLEMENTED-ARRAY-ELEMENT-TYPE of one argument
which returns the same result as:
(DEFUN IMPLEMENTED-ARRAY-ELEMENT-TYPE (TYPE)
(ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))
The type specifiers (ARRAY <type1>) and (ARRAY <type2>), where neither
<type1> nor <type2> is *, are equivalent if <type1> and <type2> produce
the same value from IMPLEMENTED-ARRAY-ELEMENT-TYPE, and disjoint
otherwise.
8. Add the function IMPLEMENTED-COMPLEX-PART-TYPE of one argument
which returns the part type of the most specialized complex number
representation that can hold parts of the given argument type.
Test cases:
Let <aet-x> and <aet-y> be two distinct type specifiers that are
definitely not type-equivalent in a given implementation, but for which
make-array will return an object of the same array type. This will be
an implementation dependent search, but in every implementation that
the proposer has tested, there will be some such types; often,
(SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.
Thus, in each case, both of the following forms return T T:
(subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
(array-element-type (make-array 0 :element-type '<aet-y>)))
(subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
(array-element-type (make-array 0 :element-type '<aet-x>)))
To eliminate the distinction between "for declaration" and "for
discrimination" both of the following should be true:
[A]
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-y>))
Since (array <aet-x>) and (array <aet-y>) are different names for
exactly the same set of objects, these names should be type-equivalent.
That implies that the following set of tests should also be true:
[B]
(subtypep '(array <aet-x>) '(array <aet-y>))
(subtypep '(array <aet-y>) '(array <aet-x>))
Additionally, to show that un-equivalent type-specifiers that use the
same specialized array type should be equivalent as element-type
specifiers, the following type tests should be true:
[C]
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-y>))
Rationale:
This proposal legitimizes current practice, and removes the obscure and
un-useful distinction between type-specifiers "for declaration" and
"for discrimination". The suggested changes to the interpretation of
array and complex type-specifiers follow from defining type-specifiers
as names for collections of objects, on TYPEP being a set membership
test, and SUBTYPEP a subset test on collections of objects.
The small differences between the specification for ARRAY and the
specification for COMPLEX are necessary because there is no creation
function for complexes which allows one to specify the resultant type
independently of the types of the parts. Thus in the case of COMPLEX
we must refer to the type of the two parts, and to the fact that a
number can be a member of more than one type. Note that:
(SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
is true in all implementations, but
(SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
is only true in implementations that do not have a specialized array
representation that can hold single-floats but not other floats.
Current Practice:
Every vendor's implementation that the proposer has queried has a
finite set of specialized array representations, such that two
non-equivalent element types can be found that use the same specialized
array representation; this includes Lucid, Vaxlisp, Symbolics, Franz,
and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
tests [A] and [C] part 2; this is a consequence of implementing the
distinction between "for declaration" and "for discrimination". Lucid
and Xerox both pass test [B], and the other implementations fail it.
No vendor that the proposer has queried has any specialized representation
for complexes.
Cost to Implementors:
This proposal is an incompatible change to the current language
specification, but only a small amount of work should be required in
each vendor's implementation of TYPEP and SUBTYPEP.
Cost to Users:
Because of the prevalence of confusion in this area, it seems unlikely
that any user code will have to be changed. In fact, it is more likely
that some of the vendors will cease to get bug reports about MAKE-ARRAY
returning a result that isn't of "the obvious type". Since the change
is incompatible, some user code might have to be changed.
Cost of non-adoption:
Continuing confusion in the user community.
Benefits:
It will greatly reduce confusion in the user community. The fact that
(MAKE-ARRAY <n> :ELEMENT-TYPE '<type>) frequently is not of type
(ARRAY <type>) has been very confusing to almost everyone.
Portability of applications will be increased slightly, since
the behavior of
(TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE <type>) '(ARRAY <type>))
will no longer be implementation-dependent.
Esthetics:
Reducing the confusing distinction between type-specifiers "for
declaration" and "for discrimination" is a simplifying step -- it is a
much simpler rule to state that the type-specifiers actually describe
the collections of data they purport to name. Thus this is a step
towards increased elegance.
Discussion:
This issue was prompted by a lengthy discussion on the Common Lisp
mailing list. It was the subject of a lengthy discussion in the
cleanup committee, as well as a number of individual efforts.
We considered the possibility of requiring that arrays remember
the element-type given in the make-array call, e.g., require that
(equal <x> (array-element-type (make-array <n> :element-type <x>)))
for all valid type specifiers <x>. This has several problems: it
increases the storage requirement for arrays, and 'hides' a
relevant part of the underlying implementation for no apparently
good reason. In addition, there might be some problems with
equivalent but separate types (although this might be handled
by changing "equal" to "equal-type", given a more rigorous
definition of SUBTYPEP; see issue SUBTYPEP-TOO-VAGUE.)
However, it would increase portability, since it would be much
more difficult to write a program that, for example, created
an array with one element-type and then assumed an upgraded
element-type. It would be valid for an implementation to do so
-- to remember the original array element-type or its canonical
or expanded form -- and satisfy all of the constraints of this
proposal.
We considered a suggestion to restrict the set of "known" array
element types; this would gain portability at the expense of limiting
the language.
----- End Forwarded Messages -----
∂08-Oct-88 1441 X3J13-mailer DRAFT Issue: DEFPACKAGE (version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 14:41:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 14:39:27 PDT
Date: 8 Oct 88 14:39 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: DEFPACKAGE (version 6)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-143927-2237@Xerox>
This issue is only marked DRAFT because there were some last minute edits
to it.
!
Issue: DEFPACKAGE
References: CLtL section 11.7.
Issue: IN-PACKAGE-FUNCTIONALITY
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 23-Mar-88, Moon, changes based on discussion
Version 3, 27-Sep-88, JonL
(remove :import, :shadowing-import; allow :export to work on
imported and inherited; update references to in-package, etc.)
Version 4, 1-Oct-88, Masinter
Version 5, 6-Oct-88, Moon
Version 6, 8-Oct-88, JonL (little nits)
Problem description:
The package functions included in CLtL encourage a programming style
that tends to evoke the worst aspects of the package system. The
problem is that if the definition of a package is scattered through
a program, as a number of individual forms, it is very easy to read
a symbol before the package setup needed to read that symbol correctly
has been accomplished. Three examples: an inherited symbol that should
have been shadowed might be accessed; a single-colon prefix might be
used for a symbol that will later be exported, causing an error; a local
symbol might be accessed where a symbol that will later be imported or
inherited was intended. These problems can be difficult to understand
or even to recognize, are difficult to recover from without completely
restarting the Lisp, and frustrating to programmers.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. In the description below,
'package-name' and 'symbol-name' can be a symbol or a string; if a symbol,
only its name matters, not what package it is in.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is a list of a keyword and arguments. Nothing in a
DEFPACKAGE form is evaluated.
Standard options for DEFPACKAGE are listed below. Options may appear
more than once (useful mainly for :IMPORT-FROM and :SHADOWING-IMPORT-FROM).
It is an error to specify :SIZE more than once.
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified names.
(:USE {package-name}*)
The package is to "use" the other designated packages; that is,
it will inherit from them.
(:SHADOW {symbol-name}*)
Create the specified symbols in the package being defined,
making them shadows, just at the function SHADOW would do.
(:SHADOWING-IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package and import
them into the package being defined, and place them on the
shadowing symbols list. In no case will
symbols be created in any package other than the one being defined;
a continuable error is signalled if no symbol is accessible in the
package named package-name for one of the symbol-names.
(:IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package and import
them into the package being defined. In no case will
symbols be created in a package other than the one being defined;
a continuable error is signalled if no symbol is accessible in the
package named package-name for one of the symbol-names.
(:INTERNAL {symbol-name}*)
Find or create symbols with the specified names. This is useful
if a :IMPORT-FROM or :SHADOWING-IMPORT-FROM option in a later
DEFPACKAGE for another package expects to find these symbols,
but the symbols are not to be exported.
(:EXPORT {symbol-name}*)
Find or create symbols with the specified names and export them.
Note an interaction with the :USE option, since intern'ing may inherit
symbols rather than creating new ones; note also an interaction
with the :INTERNAL, :IMPORT-FROM and :SHADOWING-IMPORT-FROM options,
since intern'ing will merely access an already imported symbol.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
This is an efficiency hint only, so that the package's table will
not have to be frequently re-expanded when new symbols are added
to it (e.g., by reading in a large file "in" that package.)
Additional options might be allowed by an implementation; all
implementations should signal an error if an option not recognized by
that implementation is present.
The collection of symbol-name arguments given to the options :SHADOW,
:INTERNAL, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must all be
disjoint; an error is signalled otherwise. The :EXPORT option can
be thought of as occuring after all the other options have been
executed, since it may reference names found in "used" packages,
or found in the argument lists to a :SHADOW, :INTERNAL, :IMPORT-FROM,
or :SHADOWING-IMPORT-FROM option.
DEFPACKAGE creates the package as specified, and returns it as its value.
It has no other side effects; i.e., it does not do an IN-PACKAGE.
If a package with the specified name already exists, the existing package
is modified by possibly adding to its attributes. An attempt to re-define
a package with a smaller set of attributes should signal a continuable error;
at most one such error is to be signalled per call to DEFPACKAGE, regardless
of how many attributes are being re-tracted; upon continuation, the package
is created with exactly as specified.
Examples:
;;; An example which "plays it super-safe", by using only strings as names;
;;; does not even assume that the package it is read in to "uses" LISP;
;; *never* creates any symbols whatsoever in the package that it is read
;; in to.
(LISP:DEFPACKAGE "MY-PACKAGE"
(:NICKNAMES "MYPKG" "MY-PKG")
(:USE "LISP")
(:SHADOW "CAR" "CDR")
(:SHADOWING-IMPORT-FROM "VENDOR-COMMON-LISP" "CONS")
(:IMPORT-FROM "VENDOR-COMMON-LISP" "GC")
(:EXPORT "EQ" "CONS" "FROBOLA")
)
;;; A similar call, mostly using symbols rather than strings as names.
;;; Expects to be read in to a package that "uses" LISP, and *may* create
;;; random internal symbols in that package (such as MY-PACKAGE etc).
(defpackage my-package
(:nicknames mypkg :MY-PKG) ;remember CL conventions for case
(:use lisp) ; conversion on symbols
(:shadow CAR :cdr #:cons)
(:export "CONS") ;yes, this is the shadowed one.
)
Rationale:
The availability of DEFPACKAGE encourages putting the
entire definition of a package in a single place. It also encourages
putting all the package definitions of a program in a single file, which
can be loaded before loading or compiling anything that depends on those
packages. This file can be read in the USER package, avoiding any
package bootstrapping issues.
In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Current practice:
Symbolics Common Lisp has always had a DEFPACKAGE, and uses it in
preference to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL
version of DEFPACKAGE has quite a few additional options, but none of them
appear to be necessary to propose for Common Lisp at this time. This
proposal is incompatible with Symbolics DEFPACKAGE in some ways that
will probably not cause major problems.
Cost to Implementors:
Small; DEFPACKAGE can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
Small, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
The "Put in seven extremely random user interface commands" mnemonic
described in CLtL p.191 could be removed, and the special compiler
handling of these functions necessary to support that could be removed
(except possibly for REQUIRE and PROCLAIM -- see the compiler Issue
PROCLAIM-ETC-IN-COMPILE-FILE). As this would be an incompatible change,
it is not part of this proposal.
The issue IN-PACKAGE-FUNCTIONALITY recommends that IN-PACKAGE be
incompatibly changed to recognize only existing packages, not to create
them. IN-PACKAGE would then not accept any keyword arguments.
The function MAKE-PACKAGE might also be extended to take all the keywords
that DEFPACKAGE does. This could be the subject of a separate cleanup.
The macroexpansion of DEFPACKAGE can usefully canonicalize
into the strings-as-name form, so that even though the source file
showed random symbols in the DEFPACKAGE form, the compiled file might
have only strings in it.
Frequently additional implementation-dependent options take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.
Note that we now have three continuable errors being specified, but have
not specified the condition names. This ought to be remedied.
∂08-Oct-88 1547 X3J13-mailer DRAFT Issue: DEFSTRUCT-REDEFINITION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 15:47:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 15:44:14 PDT
Date: 8 Oct 88 15:44 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: DEFSTRUCT-REDEFINITION (Version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-154414-2285@Xerox>
This issue is a draft; we need to sort out the nature of
what happens if you redefine a DEFSTRUCT with accessors
that were previously compiled, old instances, etc.
Presumably there is no groundswell for eliminating DEFSTRUCT
in favor of DEFCLASS.
!
Issue: DEFSTRUCT-REDEFINITION
References:
Category: CLARIFICATION
Edit history: Revision 1 by Skona Brittain 07/26/88
Problem Description:
The case of a structure type being redefined is not discussed in CLtL.
Proposal (DEFSTRUCT-REDEFINITION:ERROR-ITSELF):
It is an error to redefine a structure.
Proposal (DEFSTRUCT-REDEFINITION:ERROR-IFF-OLD-USE):
Redefining a structure is ok but it is an error to access, in any way,
an instance of the structure that was created prior to the redefinition.
This applies to instances of other structures that :INCLUDEd the
redefined structure.
It is also an error to use any of the redefined structures accessors
on any instances of a structure that :INCLUDEd the previous definition.
Test Cases:
(I)
(defstruct struc1
slot1 slot2)
(setq s (make-struc1 :slot1 1 :slot2 2))
(defstruct struc1 ; this is an error according to ERROR-BY-ITSELF
slot2 slot1) ; but not according to ERROR-IFF-USE
(struc1-slot1 s) ; this is an error according to ERROR-IFF-USE
(II)
(defstruct struc1
slot1 slot2)
(defstruct (struc2 (:include struc1))
slot 3)
(defstruct struc1
slot2 slot1)
(setq s (make-struc2 :slot1 1 :slot2 2))
(struc1-slot1 s) ; this is an error according to ERROR-IFF-USE
Rationale:
The issue of redefinition should be addressed since there are always
consequences that affect use of the structures: at the very least,
the constructor function gets overwritten when a structure is redefined.
ERROR-BY-ITSELF is simpler, but ERROR-IFF-USED is more amenable to use.
Current Practice:
None of KCL, Lucid, & Symbolics detect a redefinition, but all of them
return 2 as the value of the last forms in each of the above test case sets.
Cost to Implementors:
ERROR-ITSELF: none if not signaled. extremely slight if signaled.
ERROR-IFF-OLD-USE: none if not signaled. much more if signaled.
Cost to Users:
ERROR-ITSELF: It can be quite inconvenient to be prevented from "correcting"
a structure definition, which would presumably happen if the error were
signaled.
ERROR-IFF-OLD-USE: None.
Cost of Non-Adoption:
Confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Larry supports ERROR-BY-ITSELF, "in that slot-accessors for structures are
presumed to be declared "inline". If users want more flexibility than that,
they should use defclass."
Various inbetween proposals are possible, such as only incompatible
redefinitions cause errors, but they're too hard to define.
My feeling is that it's a cop-out to just say it's an error to redefine
a structure but then never signal the error - users will still be confused
by the differing seemingly erratic behavior and code.
-- - - Additional Comments - - -
"Portable programs should not dynamically redefine structures.
Programming environments are allowed, encouraged, etc. to allow such
redefinition, perhaps with warning messages. It is beyond the scope of the
language standard to define those interactions, except to note that they are not
portable.
I don't think it is a cop-out. I certainly don't want an error to be signalled.
I'm lacking a good terminology for describing the "is an error" situation that I
think this should be."
"Why not "is non-portable"?"
"We might want to at least reference the redefintion protocol of CLOS"
∂08-Oct-88 1605 X3J13-mailer Issue: DESCRIBE-INTERACTIVE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 16:05:44 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:01:29 PDT
Date: 8 Oct 88 16:01 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: DESCRIBE-INTERACTIVE (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-160129-2301@Xerox>
It seems unlikely that the cleanup committee actually has
more to say on this issue.
!
Issue: DESCRIBE-INTERACTIVE
References: DESCRIBE (p441)
Category: CLARIFICATION/CHANGE
Edit history: 12-Sep-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
Problem Description:
CLtL is not clear about whether DESCRIBE may be interactive.
While CLtL describes INSPECT as an interactive as an
interactive version of DESCRIBE, it doesn't make explicit
that DESCRIBE is non-interactive. In some implementations it is,
and in other implementations it is not.
Users of systems in which DESCRIBE is not interactive may presume
that it is safe to call DESCRIBE in a batch applications without
hanging the application, which can lead to problems.
Proposal (DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE):
Specify that DESCRIBE is permitted (though not required) to
require user input, and that such input should be negotiated
through *QUERY-IO*.
Descriptive information would continue to go to *STANDARD-OUTPUT*.
Test Case:
The following kind of interaction would be permissible in
implementations which chose to do it:
(DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
(SETF (GETHASH 'FOO *MY-TABLE*) 1)
(SETF (GETHASH 'BAR *MY-TABLE*) 2)
(SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
(DESCRIBE *MY-TABLE*)
#<EQ-HASH-TABLE 259> has 3 entries.
Do you want to see its contents? (Yes or No) Yes
Rationale:
This validates current implementations.
Current Practice:
Symbolics Genera asks some questions interactively when describing
some kinds of structured data structures, such as hash tables.
Since users can define their own DESCRIBE methods and took their cue
from the system, describing some user structures also require such
interactions.
Cost to Implementors:
None.
Cost to Users:
User code which depended on DESCRIBE running without user interaction
would have to be modified. Such code is not currently fully portable,
however.
Cost of Non-Adoption:
Users would not know the straight story about whether they should
expect interaction from DESCRIBE.
Benefits:
Implementations which don't do interactive querying in DESCRIBE only
because their not 100% sure it's kosher would be free to do it.
Aesthetics:
Some people might think it's not aesthetic for DESCRIBE to require user
intervention. Not saying whether it's permissible is probably less
aesthetic, though.
Discussion:
Pitman thinks it's important to clarify this issue, but he isn't fussy
about the particulars.
This proposal is the minimal proposal for compatibility with current
behavior.
It might be possible to extend DESCRIBE to have additional
keywords (:VERBOSE, :INTERACTIVE-ALLOWED) to cover
additional behavior.
Some members of the cleanup committee think that this is really
a change from the intent of CLtL. However, the current sentiment
is to be less rather than more specific about the behavior of debugging
tools (25.3 of CLtL).
∂08-Oct-88 1651 X3J13-mailer DRAFT Issue: DOTTED-MACRO-FORMS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 16:50:41 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:15:32 PDT
Date: 8 Oct 88 16:15 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: DOTTED-MACRO-FORMS (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-161532-2307@Xerox>
The cleanup committee (and individual members of the committee)
have mixed opinions about this issue.
!
Issue: DOTTED-MACRO-FORMS
References: forms (p54), lists and dotted lists (pp26-27),
DEFMACRO (p145), destructuring macro arguments (p146)
Category: CLARIFICATION
Edit history: 28-Jun-88, Version 1 by Pitman
1-Oct-88, Version 2 by Masinter
Problem Description:
CLtL is not explicit about whether macro forms may be dotted lists.
p54 says that only certain forms are "meaningful": self-evaluating
forms, symbols, and "lists".
pp26-27 defines "list" and "dotted list". It goes on to say
``Throughout this manual, unless otherwise specified, it is an
error to pass a dotted list to a function that is specified
to require a list as an argument.''
p146 states that in DEFMACRO destructuring, ``the argument
form that would match the parameter is treated as a
(possibly dotted) list, to be used as an argument forms list
for satisfying the parameters in the embedded lambda list.''
It goes on to say that ". var" is treated like "&rest var"
at any level of the defmacro lambda-list.
Proposal (DOTTED-MACRO-FORMS:DISALLOW):
Specify that it is an error for a macro form to be a dotted list.
Rationale:
Dotted lists are a possible symptom of program syntax error.
Allowing implementations to check for this error may catch enough
errors to justify the loss of program flexibility.
Test Case:
#1: (DEFMACRO MACW (&WHOLE W &REST R) `(- ,(CDR W)))
(MACW . 1) => ??
#2: (DEFMACRO MACR (&REST R) `(- ,R))
(MACR . 1) => ??
#3: (DEFMACRO MACX (&WHOLE W) `(- ,(CDR W)))
(MACX . 1)
(MACW . 1) would be an error under this proposal.
(MACR . 1) would be an error under this proposal.
Current Practice:
A. Some implementations bind W to (MACW . 1) in #1 and #3
and bind R to 1 in #1 and #2.
B. Some implementations bind W to (MACW . 1) in #3
and signal a syntax error in #1 and #2.
C. Some implementations signal a syntax error in #1, #2, and #3.
Symbolics Genera is such an implementation.
Cost to Implementors:
As written, this proposal doesn't require implementations to check for
the error condition.
Cost to Users:
Some users depend on this behavior in current implementations, although
such use is not widespread.
Benefits:
People would know what to expect.
Aesthetics:
Mixed opinion; certainly it is better to specify whether they are allowed
or an error than to be vague. Some feel that disallowing dotted macro
forms makes the language cleaner.
Discussion:
Goldman@VAXA.ISI.EDU raised this issue on Common-Lisp.
This issue came up primarily in the context of program-written programs;
a macro used in the program generated code might occasionally use
a dotted tail to a list to explicitly represent special conditions.
Allowing dotted macro forms may blur the data/code distinction too much,
particularly for people who are new to Lisp.
Some people believe that there's no reason to unnecessarily restrict
&WHOLE and/or &REST since there is no computational overhead and since
the interpretation, if there is one at all, is pretty well agreed upon.
- - - - - - - - Additional Discussion - - - - - -
Allow them only with a declaration?
This is an issue of error-checking vs flexibility, we think.
There is a consistency argument: dotted arguments are definitely
disallowed in function argument lists, and almost certainly allowed
in embedded macro arguments; which should the top-level macro
argument lists be consistent with?
∂08-Oct-88 1651 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 16:50:46 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:33:06 PDT
Date: 8 Oct 88 16:33 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE (Version 5)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-163306-2318@Xerox>
Our intent is to leave EQUAL and EQUALP alone. We are just having
difficulty saying what it does now.
We thought this deserved an "issue" even though it is status quo
because the issue arises frequently, and it was circulated for the
June 1988 X3J13 in a different form.
!
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CLARIFICATION/CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
08-Jun-88, Version 2 by Masinter (add Benson's proposal)
23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
01-Oct-88, Version 4 by Masinter (fix description)
01-Oct-88, Version 5 by Pitman (correct wording, add discussion)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:STATUS-QUO):
Clarify that EQUAL and EQUALP do not descend any structures or
data types other than the ones explicitly specified in CLtL.
EQUAL uses EQL for numbers and characters, descends structure for CONSes
bit-vectors, strings; has special behavior for pathnames as specified
in CLtL, and uses EQ for all other types.
EQUALP is similar, except that it ignores case in strings, and it
descends arrays, structures, and instances. It uses EQ for
all other types; for example, it does not descend hash tables.
Rationale:
There seem to be as many different equality primitives as there
are applications for them. None of the possible ways of changing
EQUAL or EQUALP are flawless. Given the inability to "fix" them,
it is better to leave them alone.
Current Practice:
We are unaware of any extensions to CLtL's set of operations,
although frequently users request them.
Cost to Implementors:
Since this seems to be compatible with the status quo, none.
Cost to Users:
Same
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
There seems to be wide debate about what the proper aesthetics for
how equality should work in Common Lisp. While the status quo is not
aesthetically more pleasing than the various alternatives, aesthetic
considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
Discussion:
An earlier version of this issue with various alternatives was distributed
at the June 1988 X3J13 meeting. Since
this is a frequently raised issue, we thought we should submit it
as a clarification although there is no change to CLtL.
Options for which we considered proposals were:
- removing EQUAL and EQUALP from the standard.
- changing EQUALP to descend structures.
- changing EQUALP to be case sensitive.
- adding a :TEST keyword to EQUAL.
- making EQUAL a generic function
All of these had some serious problems.
The cleanup committee supports option STATUS-QUO.
It would be useful if descriptions of EQUAL and EQUALP contained some sort
of additional commentary alluding to the complex issues discussed here.
The following is offered to the Editorial staff as a starting point:
Object equality is not a concept for which there is a uniquely
determined correct algorithm. The appropriateness of an equality
predicate can be judged only in the context of the needs of some
particular program. Although these functions take any type of
argument and their names sound very generic, EQUAL and EQUALP are
not appropriate for every application. Any decision to use or not
use them should be determined by what they are documented to do
rather than any abstract characterization of their function. If
neither EQUAL nor EQUALP is found to be appropriate in a particular
situation, programmers are encouraged to create another operator
that is appropriate rather than blame EQUAL or EQUALP for ``doing
the wrong thing.''
∂08-Oct-88 1651 X3J13-mailer Issue: EXIT-EXTENT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 16:50:55 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:45:27 PDT
Date: 8 Oct 88 16:45 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: EXIT-EXTENT (Version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-164527-2328@Xerox>
I think it is unlikely that the cleanup committee will
have much more to say on the issue.
!
Issue: EXIT-EXTENT
References: CATCH, THROW,
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Cleanup issue UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter, minor edits
Version 3, 7-Oct-88, by Moon, wording improvements
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
There are three cases of interest:
(1) Normal exit from a CATCH, BLOCK, or TAGBODY, or equivalent such as
PROG. A normal exit occurs when the last form in the body of one of
these constructs completes its evaluation without performing a transfer
of control. (According to CLtL p.125, there is no possibility of a
normal exit from DO.)
(2) Nonlocal exit from the target of a THROW or RETURN. A nonlocal exit
occurs when control is transferred by THROW, RETURN, or RETURN-FROM.
The CATCH or BLOCK named in the THROW, RETURN, or RETURN-FROM is
referred to as the target. The TAGBODY containing the tag named by a
GO is also referred to as the target, but GO differs from the other
nonlocal control transfer operators because GO does not exit its target.
(3) Abandonment of an exit passed over by THROW, RETURN, or GO. A
CATCH, BLOCK, or TAGBODY that is dynamically nested inside the target of
a nonlocal transfer of control is said to be passed over when control is
transferred to the target. The target itself is not said to be passed
over.
The terms "normal exit", "target", and "passed over" will be used with
these meanings for the remainder of the discussion.
CLtL is unambiguous about case 1. In case 2, the extent could end
anywhere from the time the THROW or RETURN commences, until the time the
transfer of control is completed. In case 3, the extent could end
anywhere from the time the THROW, RETURN, or GO commences, until the
time the transfer of control is completed. In case 2, it is clear that
the extent of the target ends before the transfer of control completes,
since a block cannot be exited twice, but it is not made clear whether
the extent ends before or after execution of UNWIND-PROTECT cleanup
forms. CLtL says nothing about case 3, although a note on p.38 implies
that the extent of a passed-over exit should end no later than the end
of the extent of the target exit. It would make sense for the extent
of an exit passed-over by GO to end no later than when the transfer of
control is completed, but CLtL says nothing about this.
Proposal (EXIT-EXTENT:MINIMAL):
The dynamic extent of an exit, whether target or passed-over, ends as
soon as the THROW, RETURN, or GO commences. In the language of the
implementation note on p.142, the extent ends at the beginning of the
second pass. It is an error for an UNWIND-PROTECT cleanup form executed
during a nonlocal transfer of control to attempt to use an exit whose
dynamic extent ended when the nonlocal transfer of control commenced.
This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL.
Test Cases/Examples:
Each of the following programs is an error:
(funcall (block nil #'(lambda () (return)))) ;case 1
(block nil ;case 2
(unwind-protect (return)
(return)))
(block a ;case 3
(block b
(unwind-protect (return-from a)
(return-from b))))
(let ((a nil)) ;case 1
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
(funcall (block nil ;case 3
(tagbody a (return #'(lambda () (go a))))))
(catch nil ;case 2
(unwind-protect (throw nil t)
(throw nil t)))
(catch 'a ;case 3
(catch 'b
(unwind-protect (throw 'a t)
(throw 'b t))))
The above program is an error because the catch of b is passed over by
the first throw, hence portable programs must assume its dynamic extent
is terminated. The catch is not yet disestablished and therefore it
is the target of the second throw.
The following program is not an error. It returns 10. The inner
catch of a is passed over, but this is not case 3 because that catch
is disestablished before the throw to a is executed.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
Rationale:
Giving exits the smallest extent consistent with CLtL maximizes freedom
for implementations; there are few applications, if any, that require a
longer extent.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target block or catch at the moment the values are returned, and
end the extent of a passed-over exit at the moment the THROW, RETURN, or
GO commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, the extent of a target exit lasts until the
exit has been completed; in those implementations, it is possible for a
throw or non-local exit to be effectively "stopped" by an UNWIND-PROTECT
cleanup clause that performs a nonlocal transfer of control to a
passed-over exit.
Cost to Implementors:
No currently valid implementation will be made invalid by this proposal.
Some implementors may wish to add error checks if they do not already
have them.
Cost to Users:
Since this is a clarification and current implementations differ, this
issue ostensibly does not affect current portable programs.
Cost of non-adoption:
The semantics of exits will remain ambiguous.
Benefits:
Common Lisp will be more precisely defined, and the precise definition
will be consistent with current practice in a way that has no cost for
implementors nor for users.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
One aspect of this issue, namely the particular behavior of non-local
exits from unwind protect cleanup clauses, was discussed at great
length. Some of that discussion centered around the possibility of
creating "unstoppable loops" that could not be exited, by constructs
like
(tagbody retry (unwind-protect .... (go retry)))
The goal of this proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. An alternative proposal
would define the extent of an exit to end at the last moment possible
within some particular reference implementation. That alternative would
have a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal would duck the
issue by outlawing all nonlocal exits from UNWIND-PROTECT cleanup forms.
That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
CLtL never says in what dynamic environment cleanup forms of
UNWIND-PROTECT are executed. The implementation note on p.142 may have
been intended to cover this, but since it doesn't define the term
"frame" that it uses, it doesn't actually say anything. The extent of
dynamic-extent entities other than exits should be the
subject of a separate proposal.
∂08-Oct-88 1703 X3J13-mailer DRAFT Issue: FORMAT-PRETTY-PRINT (version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:02:57 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:58:10 PDT
Date: 8 Oct 88 16:58 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FORMAT-PRETTY-PRINT (version 5)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-165810-2344@Xerox>
The only comment on this issue is on the binding of *PRINT-BASE*
under ~E, ~R, e.g. (LET ((*PRINT-BASE* 8)) (FORMAT NIL "~R" 8))
or (LET ((*PRINT-BASE* 8)) (FORMAT NIL "~E" 8.5))
!
Status: DRAFT
Issue: FORMAT-PRETTY-PRINT
References: FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category: CLARIFICATION
Edit history: Version 1 by Pierson 3/4/88
Version 2 by Pierson 5/24/88 (fix name typo)
Version 3 by Pierson 6/10/88 incorporate comments
Version 4 by Pierson 6/10/88 comments from Van Roggen
Version 5 by Masinter 2-Oct-88
Problem description:
The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively. The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.
Proposal (FORMAT-PRETTY-PRINT:YES):
Specify that FORMAT does not rebind any of the printer control
variables (*PRINT-...) except as follows:
~A
Binds *PRINT-ESCAPE* to NIL.
~S
Binds *PRINT-ESCAPE* to T.
~D
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 10.
~B
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 2.
~O
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 8.
~X
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 16.
~R
Iff a first argument is specified, binds *PRINT-ESCAPE* to NIL,
*PRINT-RADIX* to NIL, and *PRINT-BASE* to the value of the first
argument.
~@C
Binds *PRINT-ESCAPE* to T.
~F,~G,~E,~$
Binds *PRINT-ESCAPE* to NIL.
Test Cases/Examples:
(LET ((TEST '#'(LAMBDA (X)
(LET ((*PRINT-PRETTY* T))
(PRINT X)
(FORMAT T "~%~S " X)
(TERPRI) (PRINC X) (PRINC " ")
(FORMAT T "~%~A " X)))))
(FUNCALL (EVAL TEST) TEST))
This should print four copies of the above lambda expression. The
first pair should appear identical and the second pair should appear
identical. The only difference between the two pairs should be the
absence of string quotes in the second pair.
<<the test is not accurate in systems where prettyprinting
might indent differently when *print-escape* is NIL.>>
Rationale:
FORMAT should interact with the printer control variables in a
predictable way. This proposal is one of the two simplest possible
definitions and provides the most flexibility to the user.
A major advantage of this proposal is that the following two
expressions are guaranteed to have exactly the same effect:
(FORMAT stream "~S" object)
(PRIN1 object stream)
Thus use or non-use of FORMAT becomes a purely stylistic matter.
Current practice:
Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
to NIL.
Cost to Implementors:
While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications. How does a pretty-printing ~A
interact with MINCOL, etc? How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?
Cost to Users:
Truely portable code shouldn't be affected because existing
implementations are inconsistent. Despite this, there are probably a
number of user programs in non-complying which will have to change
whichever way this is decided.
Cost of non-Adoption:
The interaction of FORMAT and the printer control variables (especially
*PRINT-PRETTY*) will remain undefined. This will continue to make
portable Common Lisp programming harder than it need be.
Benefits:
Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.
Aesthetics:
The interaction between two related parts of output will be clarified
in a simple way.
Discussion:
It is important to specify exactly what of Common Lisp's special
variables get rebound by other functions and macros in Common Lisp.
This cleanup issue addresses the interaction of FORMAT and the
*PRINT- variables. There may be other similar interactions in
Common Lisp that need clarification.
Otherwise, code that depends on FORMATs action in one implementation
will not port to others that do not have the same behavior.
CLtL might change as follows:
Add a header "Printer Control Variables" before the description of
*PRINT-ESCAPE* on page 370.
Add the following paragraph to page 386 just before the paragraph
starting with "It is an error":
"The FORMAT function by itself never binds any of the printer
control variables. Specific FORMAT directives bind exactly the
printer control variables specified in their description. While
implementations may specify the binding of new, implementation
specific printer control variables for each FORMAT directive, they
may neither bind any standard printer control variables not
specified in description of a FORMAT directive nor fail to bind
any standard printer control variables as specified in the
description."
∂08-Oct-88 1726 X3J13-mailer DRAFT Issue: FUNCTION-COMPOSITION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:26:34 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 17:20:36 PDT
Date: 8 Oct 88 17:20 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FUNCTION-COMPOSITION (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-172036-2376@Xerox>
The comments on this issue so far deal with the possibility
of removing :TEST-NOT, and some minor problems with the
definition of COMPOSE. (E.g., (COMPOSE) might return
#'VALUES.)
However, comment on the main issue, whether this is important
enough to add to the language, is welcome.
!
Status: DRAFT
Issue: FUNCTION-COMPOSITION
References: None
Category: ADDITION
Edit history: 21-Jun-88, Version 1 by Pitman
05-Oct-88, Version 2 by Pitman
Related-Issues: TEST-NOT-IF-NOT
Problem Description:
A number of useful functions on functions are conspicuously
absent from Common Lisp's basic set. Among them are functions
which return constant T, constant NIL, and functions which
combine functions in common, interesting ways.
Proposal (FUNCTION-COMPOSITION:NEW-FUNCTIONS):
Add the following functions:
COMPOSE &REST functions [Function]
Returns a function whose value is the same as the composition
of the given functions. eg, (FUNCALL (COMPOSE #'F #'G #'H) A B C)
is the same as (F (G (H A B C))). Also, for example, #'CAADR may
be described as (COMPOSE #'CAR #'CAR #'CDR).
CONJOIN &REST functions [Function]
Returns a function whose value is the same as the AND of the
given functions applied to the same arguments.
DISJOIN &REST functions [Function]
Returns a function whose value is the same as the OR of the
given functions applied to the same arguments.
COMPLEMENT function [Function]
Returns a function whose value is the same as the NOT of the
given function applied to the same arguments.
ALWAYS value [Function]
Returns a function whose value is always VALUE.
Examples:
(MAPCAR #'(LAMBDA (X) (DECLARE (IGNORE X)) T) '(3 A 4.3))
==
(MAPCAR (ALWAYS T) '(3 A 4.3))
=> (T T T)
(MAPCAR #'(LAMBDA (X) (AND (NUMBERP X) (ZEROP X))) '(3 A 0.0))
==
(MAPCAR (CONJOIN #'NUMBERP #'ZEROP) '(3 A 0.0))
=> (NIL NIL T)
(FIND-IF #'(LAMBDA (X) (AND (INTEGERP X) (SYMBOLP X))) '(3.0 A 4))
==
(FIND-IF (DISJOIN #'INTEGERP #'SYMBOLP) '(3.0 A 4))
=> A
(FUNCALL #'(LAMBDA (&REST X) (REVERSE (APPLY #'LIST* X))) 3 4 5 '(6 7))
==
(FUNCALL (COMPOSE #'REVERSE #'LIST*) 3 4 5 '(6 7))
=> (7 6 5 4 3)
(FIND-IF-NOT #'ZEROP '(0 0 3))
==
(FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
=> 3
Rationale:
The presence of these functions will contribute to syntactic
conciseness in some cases, and more importantly will permit
a programming style which is currently discouraged by most
Common Lisp implementations.
It is technically possible to define this functionality portably,
the really important part of this proposal is that native compiler
support is needed to really do them justice. Portable implementations
are not likely to be efficient enough for serious use.
Placing these functions in the core language not only permits
but encourages a very useful set of compiler optimizations that
would otherwise be difficult to obtain.
In principle, a proposal to flush the :TEST-NOT keywords and the
-IF-NOT functions could even be entertained if the COMPLEMENT
function were added. [See issue TEST-NOT-IF-NOT.]
Current Practice:
No Common Lisp implementations provide these primitives, but they do
exist in the T language.
Cost to Implementors:
A straightforward implementation is simple to cook up. The definitions
given here would suffice. Typically some additional work might be
desirable to make these open code in interesting ways.
(DEFUN COMPOSE (&REST FUNCTIONS)
(COND ((NOT FUNCTIONS)
(ERROR "COMPOSE requires at least one function."))
((NOT (REST FUNCTIONS))
(FIRST FUNCTIONS))
(T
(LET ((REVERSED-FUNCTIONS (REVERSE FUNCTIONS)))
(LET ((LAST-FUNCTION (FIRST REVERSED-FUNCTIONS))
(OTHER-FUNCTIONS (REST REVERSED-FUNCTIONS)))
#'(LAMBDA (&REST ARGUMENTS)
(DO ((O OTHER-FUNCTIONS (CDR O))
(VAL (APPLY LAST-FUNCTION ARGUMENTS)
(FUNCALL (CAR O) VAL)))
((NULL O) VAL))))))))
(DEFUN CONJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL T (AND VAL (APPLY (CAR F) ARGUMENTS))))
((OR (NULL VAL) (NULL F)) VAL))))
(DEFUN DISJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL NIL (OR VAL (APPLY (CAR F) ARGUMENTS))))
((OR VAL (NULL F)) VAL))))
(DEFUN COMPLEMENT (FUNCTION)
#'(LAMBDA (&REST ARGUMENTS)
(NOT (APPLY FUNCTION ARGUMENTS))))
(DEFUN ALWAYS (VALUE)
#'(LAMBDA (&REST ARGUMENTS)
(DECLARE (IGNORE ARGUMENTS))
VALUE))
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
(COMPLEMENT BENEFITS)
Benefits:
Some code would be more clear.
Some compilers might be able to produce better code.
Takes a step toward being able to flush the -IF-NOT functions
and the :TEST-NOT keywords, both of which are high on the list
of what people are referring to when they say Common Lisp is
bloated by too much garbage.
Aesthetics:
In situations where these could be used straightforwardly, the
alternatives are far less perspicuous.
Discussion:
Pitman and van Roggen support the proposal.
Jim McDonald (JLM@Lucid.COM) seemed supportive of this proposal
and even suggested adding more elaborate operators such as
PERMUTE and COMMUTE. eg, (COMMUTE #'CONS) would be like what
Maclisp called XCONS.
Masinter wavered on this issue, but currently seems to support it.
Fahlman thinks this slightly gratuitous but is not opposed to
it if others think it is a good idea.
∂08-Oct-88 1726 X3J13-mailer DRAFT Issue: FUNCTION-COERCE-TIME (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:26:25 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 17:10:18 PDT
Date: 8 Oct 88 17:10 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FUNCTION-COERCE-TIME (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-171018-2362@Xerox>
This proposal has not yet been resolved in the cleanup committee.
There are a variety of options being considered, as you can tell.
!
Status: DRAFT
Issue: FUNCTION-COERCE-TIME
References: SET-MACRO-CHARACTER (p362),
SET-DISPATCH-MACRO-CHARACTER (p364),
MAP (p249), MAPL (p129), ...
Functions using :TEST, :KEY, etc. (REDUCE, MEMBER, DELETE, ...)
Functions using a positional predicate (SORT, DELETE-IF, ...)
Category: CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
(changes to presentation of all proposals per Masinter's comments)
Status: For Internal Discussion
Problem Description:
Many functions which accept arguments which are to be treated functionally
but which are not of type FUNCTION. This functionality can be very useful,
but the time at which the coercion is accomplished must be made clear.
Proposal (FUNCTION-COERCE-TIME:LAZY):
Specify that when a non-function (eg, a symbol) is used as a functional
argument to an operator, the coercion of that non-function to a function
is delayed until the function is about to be called and is done anew
every time the function is to be called. That is, passing a non-function
functional argument, F, is equivalent to passing
#'(LAMBDA (&REST ARGUMENTS)
(APPLY F ARGUMENTS))
Rationale:
One of the main reasons that it may be useful to pass a non-function
instead of a function is to accomplish indirection which allows later
redefinitions to take proper effect. Early binding would tend to
thwart the usefulness of such indirection and force people into
notationally more clumsy devices.
Proposal (FUNCTION-COERCE-TIME:AMBITIOUS):
Specify that when a non-function (eg, a symbol) is used as a functional
argument to an operator, the coercion of that non-function to a function
is done immediately. That is, all such functions treat a non-function
functional argument, F, as if
(COERCE F 'FUNCTION)
had been passed instead.
Rationale:
This is easier to implement since the coercion is done up front and
no further worry about uncoerced functions is needed internally.
Also, inlining of mapped functions (without using temporary storage
to hold a cached value of the function being mapped) can be done
without needing to know whether the function being inlined will
affect the place which holds the functional argument being passed.
Proposal (FUNCTION-COERCE-TIME:HYBRID):
Specify that when a non-function (eg, a symbol) is used as a
functional argument to an operator, the coercion of that non-function
to a function must be done immediately if the functional argument is
to be used only internally to the function (eg, SORT or MAPCAR).
Otherwise, if the functional argument's use persists beyond the end
of the call to the operator (eg, SET-MACRO-CHARACTER), any coercion is
delayed until the function is about to be called and is done anew every
time the function is to be called.
That is, functions like SORT and MAPCAR are permitted to treat a
non-function functional argument, F, as if
(COERCE F 'FUNCTION)
had been passed instead. However, functions like SET-MACRO-CHARACTER
would treat a non-function functional argument, F, as if
#'(LAMBDA (&REST ARGUMENTS)
(APPLY F ARGUMENTS))
were passed instead.
Rationale:
Debugging is enhanced for operations such as SET-MACRO-CHARACTER
without needlessly hampering useful optimizations to things like
SORT or MAPCAR, which very rarely require this facility.
Test Cases:
(DEFVAR *SOME-FUNCTIONS*
(LIST #'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 1)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 2)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 3)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 4)))
; Control situation A
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'(LAMBDA (&REST X) (APPLY #'FOO X))
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4)
; Control situation B
(LET ((FOO (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))))
(LIST (MAPCAR FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 1 1) 4)
; Interesting Situation 1
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-1
or ((1 1 1 1) 4) ;Ambitious-1
; Interesting Situation 2
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR 'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-2
or ((1 1 1 1) 4) ;Ambitious-2
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(EXPT (READ STREAM) (OR N 1)))
(SET-DISPATCH-MACRO-CHARACTER #\# #\$ 'SHARP-DOLLAR)
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3 81)
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(+ (READ STREAM) (* (OR N 0) 0.01)))
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3.0 3.04) ;Lazy-3
(3 81) ;Ambitious-3
Proposal LAZY requires LAZY-1, LAZY-2, LAZY-3.
Proposal AMBITIOUS requires AMBITIOUS-1, AMBITIOUS-2, AMBITIOUS-3.
Proposal HYBRID requires AMBITIOUS-1, AMBITIOUS-2, LAZY-3.
Current Practice:
Implementations are permitted to differ in when they do the coercion since
the coercion time is not clearly spelled out.
(In the test case, LAZY-1 can occur only if MAPCAR is inlined, and then
only if the original value of the function definition is not cached.)
[Some info below is based on empirical testing -- I didn't look at the
source or try to see how speed/safety affect things. -kmp]
Symbolics Genera implements AMBITIOUS-1 interpreted and LAZY-1 compiled.
Symbolics Cloe (a compiled-only lisp) implements LAZY-1 both `interpreted'
and compiled.
Both Symbolics Genera and Symbolics Cloe implement LAZY-2.
Symbolics Genera implements LAZY-3.
Symbolics Cloe implements AMBITIOUS-3.
Cost to Implementors:
[Costs may vary widely depending on current practice.
I'll leave this one open for now pending feedback from others. -kmp]
Cost to Users:
This change is upward compatible.
Cost of Non-Adoption:
A very important aspect of the language would be left unspecified.
Portability would suffer.
Benefits:
HYBRID has the benefit of making things like readmacros easier to debug.
LAZY offers the additional benefit of being able to repair certain
functional arguments to SORT or MAPCAR (eg, as a symbol) in the debugger,
and then to proceed the error (in implementations offering that restart
option) in a way that makes the ongoing call to SORT or MAPCAR notice
the repairwork right away.
Aesthetics:
Since this is a visible aspect of the language, anything which clarified
the behavior that a programmer might expect would seem to improve the
aesthetics somewhat.
Discussion:
This issue was raised by Nick Gall and written up by Pitman.
Pitman supports FUNCTION-COERCE-TIME:HYBRID.
∂08-Oct-88 1741 X3J13-mailer DRAFTIssue: HASH-TABLE-ACCESS (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:41:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 17:35:50 PDT
Date: 8 Oct 88 17:35 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFTIssue: HASH-TABLE-ACCESS (version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-173550-2380@Xerox>
!
Status: DRAFT -- see comments at end
Issue: HASH-TABLE-ACCESS
References: hash-tables (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 13-Sept-88, version 1 by Walter van Roggen
Problem Description:
There are many characteristics of hash-tables which are specified upon
creation but are not accessible afterwards.
Proposal: (HASH-TABLE-ACCESS:PROVIDE)
Add the following functions to the language:
HASH-TABLE-REHASH-SIZE hash-table
Returns the current rehash size of a hash table.
HASH-TABLE-REHASH-THRESHOLD hash-table
Returns the current rehash threshold of a hash table.
HASH-TABLE-SIZE hash-table
Returns the current size of a hash table.
HASH-TABLE-TEST hash-table
Returns the test used for comparing keys in the hash table.
By default the value will be EQL.
Current Practice:
VAX LISP implements the proposal.
Cost to Implementors:
Most of these should be trivial to implement, since the information
must be present for nearly all types.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
For example, it would allow programs to gain statistics about hash
table usage that might enable better tuning.
Discussion:
None of these are required to be SETF'able, though that might be
a reasonable implementation-dependent extension.
This first appeared in ">GLS>clarifications.text" of 12/06/85.
- - - - -
Is it reasonable for implementations to extend the set of SETF-able forms? It
would seem to lead to more subtle incompatibilities, because there would be no
simple lexical analysis that would determine the use of an extension vs the
standard. Further, I don't think that HASH-TABLE-SIZE HASH-TABLE-TEST, are
reasonably SETF-able. If you change the :TEST, would would you do about entries
that now collide?
It would make more sense to make HASH-TABLE-REHASH-SIZE
HASH-TABLE-REHASH-THRESHOLD
both SETFable if it is reasonable to expect to do so.
I wonder before we add more slots for built in data structures if
we wouldn't be doing better if we made access to these via CLOS? I won't push on
that too hard....
- - - - -
this issue is one of the very clear "Clarifications" that Guy
Steele issued on 6-Dec-1985, and which have not hitherto been turned
into format "Cleanup" proposals.
For the "Current Practice" section, you can mention that ever since the
2.0 release Lucid has provided all four accessors, as well as setf methods
for HASH-TABLE-REHASH-THRESHOLD and HASH-TABLE-REHASH-SIZE. [However,
they have not been in Lucid's documentation until the 3.0 release].
Could you be convinced to ask the for two setf "methods" too?
One other request: the return value of HASH-TABLE-TEST should
be among the values of 'EQ, 'EQL, or 'EQUAL -- not among #'EQ,
#'EQL, or #'EQUAL.
∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:41:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 17:30:01 PDT
Date: 8 Oct 88 17:30 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-173001-2379@Xerox>
!
Status: DRAFT -- several issues raised not addressed here
Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
References: CLtL pp 47-48, 158-159
Category: CHANGE
Edit history: #1, 7 Sept 1988, Walter van Roggen
#2, 13 Sept 1988, Walter van Roggen (costs & proposal limitations)
Problem description:
The current description of the specialized FUNCTION type specifier is not very
useful to program analysis tools and is not very intuitive to programmers
because the meaning of the argument type specifiers is not restrictive.
Programmers find it useful to add information about the types of the arguments
a function expects and about the type(s) that a function may return. This
information is useful both to human readers of the code as well as to type
checking programs such as compilers and cross referencers. The only apparent
(but false) way of providing this information is with the FTYPE declaration and
FUNCTION type specifier.
Furthermore, implementations may wish to provide additional optimizations based
on avoiding type checking or different methods of argument passing. These
optimizations require the same sort of information about the argument types.
However, the current definition of FUNCTION type specifiers on pages 47-48 of
CLtL states that a function such as CONS that is of type
(FUNCTION (T T) CONS)
is also of type
(FUNCTION (FLOAT STRING) LIST).
Unfortunately this information is not useful for the above mentioned purposes.
The problem is that the argument types aren't restrictive, so no interesting
matching of types is possible.
Another way of looking at the problem is that specialized FUNCTION type
specifiers cannot be used in a meaningful way for discrimination (as the second
arg to TYPEP, nor as the first argument to THE). Furthermore functions are
assumed not to be sufficiently self-descriptive that a specialized FUNCTION
type is possible to be known or can be constructed when a function is passed to
TYPE-OF.
Thus unlike all the other type declarations, which can be used for
discrimination and have an implicit effect on representation, specialized
FUNCTION type specifiers appear to have superfluous information. By changing
the meaning of the argument types to convey additional descriptive information
instead of behavioral information, we can also satisfy the other needs listed
above.
Proposal (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE)
For specialized FUNCTION type specifiers
(proclaim '(ftype (function (arg0-type arg1-type ...) val-type) f))
implies
(the val-type (f (the arg0-type ...) (the arg1-type ...) ...))
If the arguments to F are of the specified types, then the result will be of
the specified type. If the arguments do not all match the specified types, it
is an error, and then the result is not guaranteed to be of the specified type.
This proposal does not alter the status (or lack thereof) of other issues
related to FUNCTION type specifiers: what lambda-list keywords mean, what the
VALUES type means, what implications there are w.r.t. argument counts, doing
multiple PROCLAIMs, doing local DECLAREs that shadow other declarations or
proclamations, describing generic functions incrementally, the result of TYPEP
with a specialized FUNCTION type.
Rationale:
The proposal seems most like what users expect.
Current Practice:
VAX LISP already assumes and makes use of the "restrictive" semantics. Lucid
has a RESTRICTIVE-FTYPE declaration with these semantics and ignores the
standard FTYPE declaration. Gold Hill intends to use these declarations in this
manner. Many implementations don't make use of these declarations. At least
several users make use of declarations assuming the new semantics.
Cost to Implementors:
Since most implementations don't make use of function declarations, and since
those known to do so can be changed easily, the cost should be minimal.
Cost to Users:
There may be some existing "imprecise" function declarations. However, the
natural tendency when providing these declarations is to be as "descriptive"
(i.e., restrictive but complete) as possible, both for documentation purposes
as well as for potential compiler benefits. There cannot have been any uses of
the specialized FUNCTION type for discrimination. Thus most existing uses are
probably compatible with this new definition.
Cost of Non-Adoption:
There already exists user code on many implementations that assume the
proposed semantics. Not adopting this proposal would continue to render
such code incorrect or at least non-portable.
Benefits:
Better type checking and more compiler optimizations should be possible.
Esthetics:
This is the what most programmers expect the specialized FUNCTION type to
mean, particularly those coming from other languages.
Discussion:
Is it the case that this proposal makes no statement on the issue of
what happens if you do multiple proclamations for the same function?
I don't think you can completely ignore the issue because
(FUNCTION (FIXNUM FIXNUM) CONS)
is a proper global declaration for CONS if multiple declarations are
permitted, but not if only one declaration is permitted.
I think that much of the confusion about function type declarations is
because there are two aspects of the issue that have not been clearly
delimited:
1. Declarations describing the definition of a function.
2. Declarations about functions expected to be received by an argument
or variable.
The proposal FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE addresses
the first case, while the discussion in CLtL seems to have primarily the
second case in mind.
- - - - -
The function type constructor is anti-
monotonic in its first argument, unlike most other other type constructors
which are monotonic in all arguments. That is,
If X is a subtype of Y
then Z --> X is a subtype of Z --> Y
but Y --> Z is a subtype of X --> Z.
It would be good if Common Lisp's notion of "type" and "subtype" could
be made consistent with this fact.
∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:41:35 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 17:38:18 PDT
Date: 8 Oct 88 17:38 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-173818-2382@Xerox>
!
Issue: HASH-TABLE-PACKAGE-GENERATORS
References:
Category: ADDITION
Edit history: Version 1, 23-May-88 JonL
Version 2, 6-Oct-88 JonL (convert to "with" scoping).
Version 3, 7-Oct-88 JonL (mly's syntax for package iterator)
Problem description:
The Iteration subcommittee would like the several iteration proposals to be
writeable in portable Common Lisp code. Unfortunately, the only complete
access to hash-tables and packages is through MAPHASH and DO-SYMBOLS (and
DO-EXTERNAL-SYMBOLS and DO-ALL-SYMBOLS); none of these existing primitives
is satisfactory for building complex iteration clauses.
Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER)
Add two new macros WITH-HASH-TABLE-ITERATOR and WITH-PACKAGE-ITERATOR
to the language as follows:
WITH-HASH-TABLE-ITERATOR ((<next-fn> <hash-table>) &body body) [Macro]
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return the items, one by one, from the hash-table which is obtained
by evaluating <hash-table> [only once].
An invocation (<next-fn>) returns three values as follows:
;; 1. a boolean indicating whether an entry is returned (T says yes)
;; 2. the key item (of a <key, value> pair)
;; 3. the value item (of a <key, value> pair)
;; After all entries have been returned [by successive invocations of
;; (<next-fn>)], then only one value is returned, namely NIL.
WITH-PACKAGE-ITERATOR ((<next-fn> <package> [Macro]
&key external internal inherited)
&body body)
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return the items, one by one, from the package which is obtained
by evaluating <package> [only once].
An invocation (<next-fn>) returns three values as follows:
;; 1. a boolean indicating whether an entry is returned (T says yes)
;; 2. a symbol (available in the indicated package)
;; 3. the availability type for that symbol; i.e. one of
;; :INTERNAL, :EXTERNAL, or :INHERITED, or unspecified for
;; the DO-ALL-SYMBOLS case.
;; After all entries have been returned [by successive invocations of
;; (<next-fn>)], then only one value is returned, namely NIL.
The keyword arguments are flags indicating which kinds of symbols are
wanted; they are not "evaluated". The following combinations are
recognized:
+----------+----------+-------------+--------------------------------------
| external | internal | inherited | CLtL macro equivalent
+----------+----------+-------------+-------------------------------------
| T | T | T | DO-SYMBOLS
| T | T | NIL | DO-PRESENT-SYMBOLS [not CLtL]
| T | NIL | T | <none> [unspecified]
| T | NIL | NIL | DO-EXTERNAL-SYMBOLS
| NIL | T | T | <none> [unspecified]
| NIL | T | NIL | DO-INTERNAL-SYMBOLS [not CLtL]
| NIL | NIL | T | DO-INHERITED-SYMBOLS [not CLtL]
| NIL | NIL | NIL | DO-ALL-SYMBOLS
+----------+----------+-------------+--------------------------------------
In the default case, equivalent to DO-ALL-SYMBOLS, the value of the
<package> argument is ignored. The lines marked "[not CLtL]" mention
package iterator macros found in some implementations of Common Lisp;
their meaning should be self-explanatory. The lines marked "unspecified"
may be extended by an implementation to have the implied meaning.
In accord with common practice, the options that include "inherited"
symbols, and the DO-ALL-SYMBOLS option, are allowed to present the
same symbol multiple times. This is because a symbol may be "inherited"
from several different used packages; and a symbol may be present in
several different packages (in the DO-ALL-SYMBOLS case).
It is unspecified what happens if any of the implicit interior state
of an iteration is returned outside the dynamic extent of the WITH-...
form (such as by returning some closure over the invocation form).
Test-case:
The following function should return T on any hash-table, and signal
an error if the usage of 'with-hash-table-iterator' doesn't agree
with the corresponding usage of 'maphash'.
(defun test-hash-table-iterator (hash-table)
(let ((all-entries '())
(generated-entries '())
(unique (list nil)))
(maphash #'(lambda (key value) (push (list key value) all-entries))
hash-table)
(with-hash-table-iterator (generator-fn hash-table)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? key value) (generator-fn)
(unless more? (return))
(unless (eql value (gethash key hash-table unique))
(error "Key ~S not found for value ~S" key value))
(push (list key value) generated-entries))))
(unless (= (length all-entries)
(length generated-entries)
(length (union all-entries generated-entries :test #'equal)))
(error "Generated entries and Maphash entries don't correspond"))
t))
The following function should return T on any package, and signal
an error if the usage of 'with-package-iterator' doesn't agree
with the corresponding usage of 'do-symbols'.
(defun test-package-iterator (package)
(unless (packagep package)
(setq package (find-package package)))
(let ((all-entries '())
(generated-entries '()))
(do-symbols (x package)
(multiple-value-bind (symbol accessibility)
(find-symbol (symbol-name x) package)
(push (list symbol accessibility) all-entries)))
(with-package-iterator (generator-fn package
:internal t :external t :inherited t)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? symbol accessibility) (generator-fn)
(unless more? (return))
(let ((l (multiple-value-list (find-symbol (symbol-name symbol)
package))))
(unless (equal l (list symbol accessibility))
(error "Symbol ~S not found as ~S in package ~A [~S]"
symbol accessibility (package-name package) l))
(push l generated-entries)))))
(unless (and (subsetp all-entries generated-entries :test #'equal)
(subsetp generated-entries all-entries :test #'equal))
(error "Generated entries and Do-Symbols entries don't correspond"))
t))
The following functions prints out every interned symbol:
(defun print-all-symbols ()
(with-package-iterator (next-symbol nil)
(print (next-symbol))))
Rationale:
The particular way in which hash-tables and packages are represented
need not be standardized, or even exposed to the user. Yet a simpler
handle on them is needed for the various iteration paradigms to be written
in portable code. In fact, after these iterator macros are put into an
implementation, then MAPHASH and DO-<mumble>-SYMBOLS are trivial usages
of them; but no _efficient_ use of the current primitives will provide
the effect of the new macros, namely a form that _returns_ the elements
of a table "one by one".
Current Practice:
Nobody does it this way, but both Symbolics and Lucid are not far off.
Cost to Implementors:
Moderate. Possibly a couple day's to a week's work for an implementation
that has to start completely afresh. Something like this is already being
done by the standard package macros [CLtL, p187].
Cost to Users:
None.
Benefits:
Will provide a more basic primitive for iterating over hash-tables and
packages; will permit new iteration paradigms to be written in portable code.
Aesthetics:
All other things being equal, it is better to have more general primitives
than less general ones.
Discussion:
The Iteration Subcommittee supports this proposal (or, "used to" --
JonL 6-Oct-88).
One must be careful not to assume that the invocation (<next-fn>) is a
"generator" function call -- since <next-fn> is MACROLET'd in an
implementation dependent way, it could even turn into a special form like
(if something
(values nil)
(yet-another-function-call))
The scoping called for herein may not be quite so useful to the "generators"
style proposals; in particular they offer an interface wherein one may
create a "generator" function of indefinite extent that returns, one-by-one,
the elements of the table. The constrained scoping implicit in these
WITH-... macros is not so much for any kind of optimization, but rather
for coordination of such hash-table "locking" as may occur in multi-
processing implementations like Symbolics. Nevertheless, Dick Waters
thinks these macros should be put in anyway, since it clearly is a
requirement for a portable LOOP, and can be use in a limited context
(i.e., not "indefinite scope") for portable versions of ITERATE and OSS.
Of course, if an implementation _can_ support an indefinite extent for
a "generator" object returned out of the iterator forms, it is allowed
to do so by this proposal.
∂08-Oct-88 1751 X3J13-mailer DRAFT Issue: HASH-TABLE-PRINTED-PREPRESENTATION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:51:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 17:44:14 PDT
Date: 8 Oct 88 17:43 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: HASH-TABLE-PRINTED-PREPRESENTATION (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-174414-2396@Xerox>
The issues listed under Additional Comments still have not been resolved.
!
Status: DRAFT (see Additional Comments)
Issue: HASH-TABLE-PRINTED-PREPRESENTATION
Category: ENHANCEMENT
Edit history: 23-May-88, Version 1 by Touretzky
8-Jun-88, Version 2 by Masinter (as per cl-cleanup discussion)
Description:
Hash tables are currently second-class data structures when compared to
lists, vectors, and structures, because they have no READable printed
representation. This proposal introduces a #H reader syntax for hash
tables and a switch to control when hash tables will be printed this way.
Proposal (HASH-TABLES-PRINTED-REPRESENTATION:#H-NOTATION) :
1) Introduce the following reader notation for hash tables:
#nH(type (k1 v1) (k2 v2) ...)
"n" is the size of the table; it is analagous to the :size argument to
MAKE-HASH-TABLE. If omitted, the system picks some reasonable size.
"type" is one of EQ, EQL, or EQUAL. If omitted it defaults to EQL.
The (ki vi) pairs consist of a key and a value. There may be any number of
such pairs, including zero. Order is not significant. It is an error for
two keys to be identical (using the EQ, EQL, or EQUAL test, as
appropriate.)
2) Introduce a switch called *PRINT-HASH* whose initial value is
implementation-dependent. If *PRINT-HASH* is T, hash tables are printed
using the #H syntax (with all optional components supplied), subject to the
usual limits imposed by *PRINT-LEVEL* and *PRINT-LENGTH*. If *PRINT-HASH*
is NIL, hash tables are printed using the current #<HASH-TABLE ...> syntax.
Rationale:
This is a useful upward compatible extension (except in
implementations that have usurped #H for other purposes), with very
low adoption cost.
Cost to Implementors:
A simple change to PRIN1 and the pretty printer. Most of the code
will be similar to existing routines for printing vectors in #()
notation and arrays in #nA() notation. The reader would change to
read this notation.
Cost to Users:
Small. Programs that want to control all *PRINT- parameters will need
to know about yet another parameter.
Benefits:
This proposal makes hash tables first class objects. If
*PRINT-HASH* is T, their contents become visible in all the normal ways,
e.g., if FOO is bound to a hash table object, then typing FOO to a
read-eval-print loop will display the contents of the hash table. Hash
table contents may also be displayed by TRACE if the table is passed as an
argument; they may also be displayed by the debugger. Finally, hash tables
may be appear as literal objects in programs and be read or written to files.
Current practice:
We know of no current implementations of this proposal.
Although some implementations allow the user to see hash table contents
with DESCRIBE or INSPECT, not all do. CMU Common Lisp's DESCRIBE, for
example, does not show hash table contents. This reinforces the need for
a standard #H notation to guarantee that users can manipulate a hash table
as easily as a vector, array, or structure.
Discussion:
Several alternatives have been suggested for the syntax of #H.
- preferred notation: #H(EQL (FOO 37) (BAR 42))
- dotted pair notation: #H(EQL (FOO . 37) (BAR . 42))
- property list: #H(EQL FOO 37 BAR 42)
- pseudo-structure: #S(HASH-TABLE TYPE EQL SIZE 20 INITIAL-CONTENTS ((FOO 37) (BAR 42)))
One problem with the currently proposed #H notation is that it provides no
way to specify a rehash-size or rehash-threshold. This should not be a
fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is also
shared by #nA notation. Some object that the fact that #A is flawed is no
reason to introduce the same flaw elsewhere.
This prompted yet another proposal:
#[size]H([type] [rehash-size] [rehash-threshold] (ki vi)*)
e.g. #65H(EQL 101 65 (FOO 37) (BAR 42))
along with alternative settings for *PRINT-HASH*, NIL, T, :BRIEF, where the
latter would leave out all of the options.
- - - - Additional Comments - - - - -
you still can't
call the objects "first class" if the printed representation cannot be
read in as an equivalent copy; and the fact that CL has some other datatypes
that aren't "first class" doesn't argue for doing something substandard
for hash-tables.
One problem with the currently proposed #H notation is that it provides
no way to specify a rehash-size or rehash-threshold. This should not be
a fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is
also shared by #nA notation.
I think this is a fatal flaw. The fact that *some* complex classes of
arrays also share this fatal flaw is no argument for retaining it. It
is still the case that simple arrays of the more common element types
do not have the flaw; and several years ago there was some discussion
on how to fix other manifestations of the flaw on multi-dimensional arrays.
∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: FUNCTION-DEFINITION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:41:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 17:25:54 PDT
Date: 8 Oct 88 17:25 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FUNCTION-DEFINITION (Version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-172554-2377@Xerox>
This issue is still actively being developed, as you can see.
This is just some evidence that we're working on it.
!
Status: DRAFT
Issue: FUNCTION-DEFINITION
References: none
Category: ADDITION
Edit history: 23-Jun-88, Version 1 by Pitman
Problem Description:
There are portable ways to turn symbols and lists into functions,
but there are no portable ways to get back the original symbols and
lists given the functions.
Proposal (FUNCTION-DEFINITION:OPTIONAL):
Introduce a new function called FUNCTION-DEFINITION which took as
its argument a function and returned three values:
#1: its ``definition'' as a symbol or list, or NIL if the
information was no longer available.
#2: NIL if the definition was enclosed in the null lexical
environment and something non-NIL if the definition was (or
might have been) enclosed in some non-null lexical environment.
[It is always safe for an implementation to return T for this
value.]
#3: the `name' of this function. the name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations would be free to not record this information, or to provide
primitives for flushing some or all of the information at any time.
Examples:
The following examples illustrate some possible return values, but
are not not intended to be exhaustive:
#1: (FUNCTION-DEFINITION #'(LAMBDA (X) X))
or (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
#2: (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) NIL), T, NIL
but -not- (LAMBDA (X) X), NIL, NIL
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION #'BAR) #'FOO)
(DEFUN FOO (Y) Y)
(FUNCTION-DEFINITION #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, FOO
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-DEFINITION (FOO))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) X), T, "BAR in FOO"
Rationale:
This functionality would be useful to the pretty printer, debugger,
inspector, and other tools.
Cost to Implementors:
Because NIL can be returned as a first value, the amount of work forced
by this proposal is trivial. The following implementation is technically
legitimate, although many implementations would want to provide something
more useful:
(DEFUN FUNCTION-DEFINITION (FUNCTION)
(CHECK-TYPE FUNCTION FUNCTION)
(VALUES NIL NIL NIL))
Proposal (FUNCTION-DEFINITION:REQUIRED):
Introduce a new function called FUNCTION-DEFINITION which took as
its argument a function and returned three values:
#1: its ``definition'' as a symbol or list, or NIL if the
information was no longer available.
#2: NIL if the definition was enclosed in the null lexical
environment and something non-NIL if the definition was (or
might have been) enclosed in some non-null lexical environment.
[It is always safe for an implementation to return T for this
value.]
#3: the `name' of this function. the name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations would be free to not record this information in file
compilations. In-core calls to EVAL and COMPILE would be required to
retain the information, however.
Examples:
The following examples illustrate some possible return values, but
are not not intended to be exhaustive:
#1: (FUNCTION-DEFINITION #'(LAMBDA (X) X))
or (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
in compiled code.
(FUNCTION-DEFINITION (EVAL '(LAMBDA (X) X)))
would not be permitted to return NIL, NIL, NIL since the compilation
occurred in the same environment.
#2: (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) NIL), T, NIL
but -not- (LAMBDA (X) X), NIL, NIL
in compiled code.
(FUNCTION-DEFINITION (FUNCALL (EVAL '(LAMBDA () #'(LAMBDA (X) X)))))
would not be permitted to return NIL, NIL, NIL since the compilation
occurred in the same environment.
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION #'BAR) #'FOO)
(DEFUN FOO (Y) Y)
(FUNCTION-DEFINITION #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, FOO
in compiled code.
If the DEFUN had been done interactively, the call to
FUNCTION-DEFINITION would not be permitted to return NIL, NIL, NIL
since the compilation occurred in the same environment.
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-DEFINITION (FOO))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) X), T, "BAR in FOO"
in compiled code.
If the DEFUN had been done interactively, the call to
FUNCTION-DEFINITION would not be permitted to return NIL, NIL, NIL
since the compilation occurred in the same environment.
Rationale:
This functionality would be useful to the pretty printer, debugger,
inspector, and other tools.
Additionally, this would be useful to programs which need to pass
around both a function and a representation of a function because a
single object could be passed which was efficient to call without
compromising the ability to reliably retrieve its representation.
Cost to Implementors:
Because NIL can be returned as a first value, the amount of work forced
by this proposal is small, but not trivial. A simple implementation
might allocate a slot in each function that could hold the definition,
or might allocate a hash table to hold the information.
Current Practice:
Many implementations record this information, but not all that do
publish an interface to extracting the information.
The language T has this operation and calls it DISCLOSE. It is the
conceptual inverse of the ENCLOSE which occurs in some Scheme dialects,
and is implemented as what CLOS would call a "generic function".
Cost to Users:
None. The change is upward compatible.
Cost of Non-Adoption:
Certain kinds of portable debugging tools would be harder to write.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
The phrase ``program is data; data is program'' comes up a lot in discussions
about Lisp. This makes the case for ``program is data'' more interesting.
Discussion:
Pitman would prefer FUNCTION-DEFINITION:REQUIRED if people would agree to it
because it is considerably more useful in practice, but would like to see at
least FUNCTION-DEFINITION:OPTIONAL.
- - - - - Additional comments - - - - - -
re: Now that we've supposedly finished with function-type,
is anybody working on a proposal to introduce a func-
tion that would retrieve the lambda-expression defini-
tion from a user-defined function object?
Lucid Common Lisp has such a function, called SOURCE-CODE. It retrieves
the lambda expression used in an interpretive definition, even after sub-
sequent compilation of the function; but it does not attempt to maintain
an "out-of-core" database like the emacs TAGS facility.
If there were to be such a function, what would be a
good name for it?
How about EXTRACT-LAMBDA-EXPRESSION ?
The T language provides such a primitive. It is called DISCLOSE
(named for symmetry with the ENCLOSE primitive which occurs in some
Scheme dialects and coerces a lambda expression into a procedure).
DISCLOSE may be overly generic-sounding for CL use, but I recommend
DISCLOSE-DEFINITION.
I assume that the proposal will allow this function to return NIL if
the original lambda expression has been compiled or optimized to the
point where it can no longer be retrieved? I wouldn't want to require
memory-tight implementations to keep around the original form in all
cases.
Since some applications for DISCLOSE have semantic impact, I don't agree
that it should be possible for an implementation to simply throw away
the information. I believe that we should spell out particular cases
in which it is or is not permissible. My personal preferences follow:
- No compiler should be required to retain the source code
when using the file compiler. That is, using COMPILE-FILE
does not make the definition available in the environment into
which the definitions are subsequently LOADed.
- I am agnostic about interactive DEFUN, etc. I am content to see
this information retained only at the discretion of the
interpreter.
- I would prefer that arguments to COMPILE be retained, and possibly
defuns done by explicit EVAL as well. The reason for this is that
programs like Macsyma which have need of this function do not just
go around peeking into arbitrary functions (in my experience). They
usually want to peek into functions that they themselves instantiated.
So primitives that allow explicit runtime instantiation of functions
on a case-by-case basis should be reliably invertible (in my opinion).
Notes:
- I would be ammenable to permitting this function to be SETF-able,
so that people could ``NIL out'' definitions they didn't want to
retain.
- I would also be ammenable to having a special argument to COMPILE
saying that the information must be retained. I don't care what
the default value was.
- If there is not any reliable situation in which a definition will
have this information retained, then all the uses I have ever had
for this except for pretty printing are nullified. Perhaps the
pretty printing argument is reason enough to have it, though.
- There is some question about whether in the case of named objects,
(DEFUN FOO (X) X)
(DISCLOSE-DEFINITION #'FOO) => (LAMBDA (X) X) or (DEFUN FOO (X) X)?
I think the latter.
Does whether FOO is still fdefined matter? I think not.
- - - - - -
After re-reading this for 30 seconds, I'd favor OPTIONAL.
(Well, maybe I actually can't tell the difference between OPTIONAL and
REQUIRED, and "OPTIONAL" sounds better to me. Maybe I'm someone who votes
for a candidate because of his accent.)
I'm a little uneasy about "-DEFINITION", because in the residential
environment biz, the "definition" is the entire DEFUN form, and not just
the lambda expression.
Is there another postfix you'd also feel comfortable with? You say Many
implementations record this information, but not all that do publish an
interface to extracting the information.
This issue should reference FUNCTION-TYPE as as part of the Problem
Statement say that this is something that people used to do with just plain
old lambda expressions, since after (DEFUN FOO (X) ...) that
(SYMBOL-FUNCTION 'FOO) would frequently return the lambda expression
directly.
Now, with KCL and HP Common Lisp, the expression you get may not match what
you put in, e.g., might have gone thru some kind of preprocessing. (I
think.)
Also, how can the "definition" be a symbol? In CommonLisp?
Didn't we go thru (SETF (SYMBOL-FUNCTION X) 'FROB) before?
∂08-Oct-88 1956 X3J13-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 19:56:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 19:52:28 PDT
Date: 8 Oct 88 19:52 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-195228-2477@Xerox>
!
Issue: LISP-SYMBOL-REDEFINITION
References: Cleanup issue PACKAGE-CLUTTER
CLtL pp 67-69 Defining named functions
Category: CLARIFICATION
Edit history: Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
Masinter, Version 2, 7-Oct-88
Masinter, Version 3, 7-Oct-88, fix typos
Problem description:
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Proposal LISP-SYMBOL-REDEFINITION:DISALLOW
The results of redefining as a function any of the functions,
macros, or special forms defined in the LISP package are unspecified;
similarly, the result of lexically defining (with FLET, LABELS or
MACROLET) any function or macro in the LISP package is unspecified.
Clarify that, as implied by CLtL p. 69, it is an error to rebind
any symbol in CL defined as a constant.
The results of applying TRACE to any function in the LISP package is
unspecified.
Following the proposed definition of "results are unspecified", this means that
implementations may signal an error, or other unspecified behavior may
ensue. For example, programming environments may warn the user about
redefinition of LISP symbols and then allow them. Some environments may
distinguish between functions that are safe to redefine and those that are
not.
Examples:
The behavior of the construct:
(FLET ((OPEN (filename &key direction) (format t "Open called....")
(OPEN filename :direction direction)))
(with-open-file (x "frob" :direction ':output)
(format t "was Open called?")))
is unspecified; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
(DEFUN CAR (X) (CDR X))
might signal an error.
Rationale:
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
Allowing arbitrary redefinition of symbols in the LISP package would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other LISP symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
Current practice:
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
Cost to Implementors:
This proposal clarifies the status quo -- that the results are unspecified. It
allows and encourages implementors to check for such redefinition, but does not
require it.
Cost to Users:
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
Benefits:
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp.
Cost of non-adoption:
Continued questions.
Esthetics:
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble.
Discussion:
There have been various proposals for allowing users to extend the "protection"
mechanism to their own macros, functions, packages. These proposals seem like
they are environment issues and not language ones, however.
It is unfortunate that the restriction on reusing LISP package symbols in
FLET, LABELS or MACROLET is necessary, but the research into straightening out
the syntactic environment of macroexpansion isn't mature enough to put into
a standard yet.
∂08-Oct-88 2035 X3J13-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 20:35:06 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 20:32:13 PDT
Date: 8 Oct 88 20:32 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-203213-2505@Xerox>
!
Issue: MAPPING-DESTRUCTIVE-INTERACTION
References: MAPCAR, MAPLIST, ... (p128);
DOLIST (p126); MAPHASH (p285);
DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS (pp187-188);
All functions using :TEST
Related-Issues: REMF-DESTRUCTION-UNSPECIFIED.
Category: CLARIFICATION
Edit history: 07-Mar-88, Version 1 by Pitman
09-Jun-88, Version 2 by Pitman
(merge Moon's comments and update current practice)
Problem Description:
The interaction of mapping functions and DOLIST with destructive
operations on the list being operated on is unclear. For example,
if you destructively modify some tail of a list being mapped down,
does that affect the mapping process?
Proposal (MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE):
Clarify that it in general is an error (the effect is not defined
but in general no error will be signalled) for code executed during a
"structure traversing" operation to destructively modify the
structure in a way that might affect the ongoing traversal operation.
For list traversal operations, this means that the cdr chain of the
list may not be destructively modified.
For array traversal operations, the array may not be adjusted and
its fill-pointer, if any, may not be changed.
For hash tables, new elements may not be added or deleted EXCEPT
that the element corresponding to the current hash key may be
changed or removed.
For packages, new symbols may not be interned in or uninterned from
the package being traversed or any package that it uses EXCEPT that
the current symbol may be uninterned from the package being traversed
in a DO-SYMBOLS.
Note: This proposal is intended to clarify restrictions on user code
for use with structure manipulators which are not inherently
destructive. Other operators, such as DELETE-DUPLICATES or NREVERSE,
may have much more complicated restrictions and are intentionally not
treated by this proposal. See the issue REMF-DESTRUCTION-UNSPECIFIED
for more discussion of such issues.
Test Case:
(LET* ((L (LIST 'A 'B 'C)) (LL L) (I 0))
(DOLIST (FOO L)
(INCF I)
(IF (EQ FOO 'B)
(SETF (CDR LL) NIL)
(POP LL)))
(LIST I L)) might return (2 (A B)) or (3 (A B)), for example.
Rationale:
This clarifies the status quo.
Also, the likelihood that the user will want to destructively alter a
structure while it is being traversed is low. The likelihood that such
code would be readable and maintainable is also low. The likelihood
that a compiler could do some interesting optimization if this point
were not pinned down is high enough to be the overriding consideration
in this case.
Current Practice:
The implementation of DOLIST in Symbolics Genera, KCL, and PopLog Common Lisp
returns (3 (A B)) for the test case.
Cost to Implementors:
None. This simply makes the status quo explicit.
Cost to Users:
Technically none. People who were mistakenly assuming that CLtL guaranteed
things which it does not might be inclined to rewrite their code in a more
portable way.
Cost of Non-Adoption:
Users would be less informed.
Benefits:
users would be more informed.
Aesthetics:
Some might say it would be clearer to define this one way or the other, but
advocates of both camps exist and their arguments are fairly symmetric.
In any case, since this is a proposal to preserve the status quo, it has no
major impact on aesthetics.
Discussion:
This idea for this proposal was suggested by the Japanese community.
Pitman drafted the formal proposal and supports the EXPLICITLY-VAGUE proposal.
Moon generally supported version 1 of this proposal, but had some specific
criticisms about weakness of the wording which this version is an attempt to fix.
∂08-Oct-88 2043 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 20:43:50 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 20:40:55 PDT
Date: 8 Oct 88 20:40 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: PACKAGE-CLUTTER (Version 4)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-204055-2507@Xerox>
!
Issue: PACKAGE-CLUTTER
References: LISP, USER, SYSTEM packages (p181)
Related issues: LISP-SYMBOL-REDEFINITION, DEFPACKAGE,
MAKE-PACKAGE-USE-DEFAULT, IN-PACKAGE-FUNCTIONALITY
Category: CHANGE/CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
5-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter (response to KMP)
Problem Description:
CLtL specifies that
``The package named LISP contains the primitives of
the Common Lisp system. Its external symbols include
all of the user-visible functions and global variables
that are present in the Common Lisp system, such as
CAR, CDR, *PACKAGE*, etc. Almost all other packages will
want to use LISP so that these symbosl will be accessible
without qualification.''
It specifies "all" but not "all and only".
Some implementations place their extensions in the Lisp package.
Nothing in CLtL explicitly prohibits this, but it leads to problems
in general. For example:
- A user defining a function by a name not mentioned in CLtL may be
surprised to clobber a system function in some implementations
- In one particular implementation, the variable HELP was a system
constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.")
signalled a correctable error (asking what variable to bind
instead of HELP :-).
Proposal (PACKAGE-CLUTTER:REDUCE):
Specify that, not only must the LISP package contain at least all of the
symbols listed in the standard, it will have no other external symbols.
(The LISP package may have additional internal symbols.)
Symbols on the LISP package may have function or macro
definitions, top level value or SPECIAL proclamations, or
type definitions only if explicitly permitted in the specification.
That is, a program is valid Common Lisp if it assumes that
this is true; for example, FBOUNDP will be false for all
external symbols of the LISP package except those documented
to be functions or macros; BOUNDP will be false for all
those except those documented to be variables,
and portable programs can use symbols in the LISP package
as local lexical variables with the presumption that the variables
are not proclaimed special, except for those variables specified
as constants or variables.
(The proposal LISP-SYMBOL-REDEFINITION addresses the
converse; that is, what user programs are allowed to do.)
Eliminate the requirement that the initial Common Lisp system
have a package named "SYSTEM". Specify that implementations may
have several other packages available, that these should be
documented. If it is appropriate, the standard might contain
as an example that implementations might have a package named
"SYSTEM".
Clarify that the "USER" package may have additional symbols interned
within it and that it may :USE other implementation-specific packages.
Examples:
#1: The symbol HELP may not be on the LISP package because it is not
mentioned in CLtL.
#2: The symbol VARIABLE is specified to be on the LISP package (because
it is a valid second argument to the DOCUMENTATION function). Since
it is not defined as a variable, type, or function, however, it will
not initially be bound, defined as a type, or defined as a function,
macro or special form.
Rationale:
If extra symbols are permitted in the LISP package, users may be surprised
by relationships between the LISP package and other packages which they
did not expect, or may be surprised by functionality that they did not
expect. The degenerate case is:
(DEFCONSTANT LISP:A 'YOU-LOSE)
(DEFCONSTANT LISP:B 'YOU-LOSE)
(DEFCONSTANT LISP:C 'YOU-LOSE)
...
(DEFCONSTANT LISP:AA 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
...etc.
Given such an implementation, even things like (LAMBDA (X) X) are not
valid because they attempt to bind "system constants". It is necessary
that the programmer be able to know for sure that an arbitrary name is
"free for use" and best way to conveniently assure this is to require
that the LISP package be unadulterated.
As for the additional definitions, there are situations where additional
definitions would cause a problem. For example, if a symbol on the Lisp
package were declared as a special variable even though that value was
not mentioned in the standard, that variable would behave incorrectly when
used as a lexical variable. Similarly, if a symbol in the lisp package
were defined as an implementation-dependent special form, problems might
result if a user redefined or even bound (as by FLET or MACROLET) that
name.
The LISP package is the foothold from which portable programs establish
their desired environment. Careful control is desirable to make sure
everyone is starting off on the right foot.
Current Practice:
Some implementations have been known to add additional symbols (usually
functional and/or variable extensions) to the LISP package.
Several implementations have restricted the LISP package to only contain
those symbols in CLtL. (The exact set was difficult to extract because not all
LISP package symbols appeared in the index of CLtL.)
Even in those implementations that have only the prescribed symbols in CLtL,
there can be extra definitions for those symbols. For example, in Symbolics Genera,
the symbols EVALHOOK, ROOM, and APPLYHOOK
are spuriously defined as special variables, and the symbol LAMBDA is defined
as a macro.
Performance Impact:
None
Cost to Implementors:
The actual cost of moving the symbols out of the LISP package in cases
where they are not already gone is quite small. However, if any
implementation really has to do this, it may have a number of suppositions
about what is in what package, and the changes could potentially be extensive.
Cost to Users:
This change is upward compatible with any portable program, but users
of a particular implementation's extensions may be forced to find their
functions in a different package, so there may be a measurable practical
cost.
In many cases where an extension symbol FOO is simply expected to have
been directly available (due to :USE "LISP"), it will work to just just
do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is
declared.
In many cases where an extension symbol FOO is used by explicit package
prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or
even `LISP:' to find the cases.
Cost of Non-Adoption:
The potential for the LISP package to be adulterated and for supposedly
portable programs to have difficulty getting a foothold in some
implementations will be `noticeably non-zero'.
Benefits:
Portability of some programs will be enhanced.
Aesthetics:
This change probably supports the naive expectation of most programmers
writing portable code.
Discussion:
This proposal basically affects what implementors are allowed to do;
it says that portable programs can rely on a standard initial package
structure with the same symbols in it. A separate proposal,
LISP-SYMBOL-REDEFINITION, discusses the restrictions on portable
programs as far as redefining LISP symbols.
Whether the USER package may contain symbols other than those
specified in the standard was controversial. The smart programmer
of portable code will never rely on the contents of the
USER package. However, if someone wants a completely empty
package that uses only Lisp, it's easy and portable to create one.
While it would improve portability slightly to disallow additional internal
symbols in the LISP package (since it affects what DO-SYMBOLS will do)
explicitly prohibiting a common practice didn't seem like the best way
to discourage a possibly troublesome implementation technique.
Implementors should be especially careful about accidentally
exporting unwanted additional definitions for symbols,e.g., a variable
definition for EVALHOOK which might show through because of
an unintended name collision.
It is likely that the recently included portions of the standard (CLOS and
the signal mechanism) will reside in their own packages. These externally
defined packages should have the same constraints as outlined for
the LISP package here.
There has been a suggestion that vendor-specific extensions should
be placed in a package named like ACME-COMMON-LISP for the "Acme"
company.
A registry of packages (as well as features, modules and other global
names) would be useful, although probably not a part of the language
standard, per se.
∂08-Oct-88 2055 X3J13-mailer Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 20:55:17 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 20:51:35 PDT
Date: 8 Oct 88 20:51 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-205135-2517@Xerox>
!
Issue: PEEK-CHAR-READ-CHAR-ECHO
References: READ-CHAR (p379), UNREAD-CHAR (p379), PEEK-CHAR (p379),
MAKE-ECHO-STREAM (p330), Streams (p327-328),
READ-PRESERVING-WHITESPACE (p376),
READ-DELIMITED-LIST (p377)
Category: CLARIFICATION/CHANGE
Edit history: 06-Mar-88, Version 1 by Pitman,
23-Jun-88, Version 2 by Pitman (remove interactive stuff)
8-Oct-88, Version 3 by Pitman & Masinter
Problem Description:
The interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM is not made adequately clear about how many times
a particular character may be echoed and at what time such echo
is permissible.
For example, given:
(WITH-INPUT-FROM-STRING (STRING-STREAM "A")
(LET ((*STANDARD-INPUT* (MAKE-ECHO-STREAM STRING-STREAM
*STANDARD-OUTPUT*)))
(LET ((CHAR NIL))
(PEEK-CHAR) (PRIN1 '---)
(PEEK-CHAR) (PRIN1 '---)
(SETQ CHAR (READ-CHAR)) (PRIN1 '---)
(UNREAD-CHAR CHAR) (PRIN1 '---)
(READ-CHAR))))
what is seen on the terminal? There are at least these possibilities:
[1] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. The first time
a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not echo,
re-fetching the char by READ-CHAR doesn't echo.
A------------
[2] Characters are echoed whenever seen by PEEK-CHAR or READ-CHAR.
Characters are not unechoed by UNREAD-CHAR.
A---A---A---A---
[3] Characters are not echoed by PEEK-CHAR but are echoed by READ-CHAR.
No `unecho' action is done by UNREAD-CHAR.
------A------A
[4] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echos
but UNREAD-CHAR does not `unecho'.
A---A---A------A
[5] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echos
but UNREAD-CHAR unechos (a magic Erase character must be
presupposed for display terminals, a file stream that can randomly
access during output and/or back up must be presupposed for files,
paper terminals just lose):
A<Erase>---A<Erase>---A---<Erase>---A
[6] PEEK-CHAR is implemented by peeking and does not echo. The first
time a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not
echo, re-fetching the char by READ-CHAR doesn't echo:
------A------
This list is not believed to be exhaustive. It is only to illustrate
of the variety of possible ways in which the current specification can
be implemented without technically being in conflict with the written
word of CLtL. Obviously not all of these interpretations are considered
useful by all people, but usefulness has not been determined to be
criterial in satisfying the specification.
The description of streams (p327-328) is also [probably deliberately]
fuzzy on this issue as it relates to operating systems on which echoing
is done by the operating system. That is, some systems are line-at-a-time
and all READ-CHAR and PEEK-CHAR operations happen after issues of echo
have long since been resolved by a system call that reads and echos input
a line at a time. Other systems are character-at-a-time and these issues
hit home in a different way. It will probably be necessary to continue
leaving things slightly unspecified in order to accomodate the native
style of the variety of operating systems now trying to support Common
Lisp, but we should be more up front about the game we are playing. (For
example, code which must port between character-at-a-time and
line-at-a-time systems must be more careful about whether it does
newline-preceded or newline-terminated output than many CL programmers
might realize given the current wording.) Additionally, though, we should
be on the lookout for less ambitious goals involving only partial
compatibility to improve the situation wherever we can find a way to.
Abstract functions READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST
are implicitly affected by any decisions made on this issue since their
descriptions involve the use of UNREAD-CHAR and PEEK-CHAR, respectively.
Proposal (PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR):
Ammend the description of READ-CHAR to say that when the stream is
an echo stream (a stream created by MAKE-ECHO-STREAM), the character
will be echoed on the stream the first time those characters are seen.
(Characters which are not echoed by READ-CHAR are those which were
put there by UNREAD-CHAR and hence are assumed to have been echoed
already by a previous call to READ-CHAR.)
Ammend the description of UNREAD-CHAR to say that when the stream
is an echo stream (a stream created by MAKE-ECHO-STREAM), no attempt
will be made to undo any echoing of the character which might already
have been done on the stream. However, characters placed on the
stream by UNREAD-CHAR will be marked in such as way as to inhibit
later re-echo by READ-CHAR.
Ammend the description of PEEK-CHAR to say that when the stream is
an echo stream (a stream created by MAKE-ECHO-STREAM), characters
which are only peeked at are not echoed. Note however that in the
case that the PEEK-TYPE argument is not NIL, the characters which
are passed by PEEK-CHAR are treated as if by READ-CHAR, and so are
echoed unless they have been marked otherwise by READ-CHAR.
Ammend the description of abstract input functions
READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST to acknowledge
that they are implicitly affected by these new echoing rules of
READ-CHAR, UNREAD-CHAR, and PEEK-CHAR.
Note: This is consistent with behavior [6] in the problem description.
Clarify that the echo behavior of interactive streams such as
*TERMINAL-IO* continues to be implementation dependent.
Rationale:
Although this is not known to be in use in any particular system,
nothing prevents its use. It proposes a more rational interpretation
of the echoing behavior of UNREAD-CHAR which might make it possible
for programmers concerned about echo behavior not to have to shy
away from UNREAD-CHAR. (It would probably also improve the behavior
of READ-PRESERVING-WHITESPACE with regard to echoing, since its
description mentions using UNREAD-CHAR.)
Correct echoing behavior is important to programs which do batch
processing, parsing, etc. Allowing multiple or premature echoing
is clearly unsatisfactory.
Current Practice:
A wide variety of behaviors are in use.
Cost to Implementors:
Unknown.
The code to implement the proposed change itself is probably fairly
localized.
In some operating systems, there may be echoing constraints which
are overlooked here.
In some cases, there may be second order effects in the system
itself which would also require a somewhat less predictable amount
of work to fix.
Cost to Users:
Any change is effectively upward compatible since the previous
behavior is so ill-specified.
Most users probably naively expect (perhaps even without realizing
it explicitly) that echoing will take care of itself. That is, they
probably expect that echoing will occur at the time of the
READ-CHAR and probably do not give a lot of thought to the effect
of PEEK-CHAR. As such, FIRST-READ-CHAR probably best supports most
of their naive intuitions.
Cost of Non-Adoption:
The streams returned by MAKE-ECHO-STREAM would continue to be
significantly hard to use portably.
Benefits:
A number of applications involving of parsers, batch script
interpreters, and such would be possible to implement
straightforwardly and portably.
Aesthetics:
?
Discussion:
Pitman supports PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR because
he feels it is more practically coherent. However, he says he has
only mental exercises and no actual personal experience upon which
to base that belief.
Version 1 of this proposal treated interactive streams on par
with echo streams, but while people agreed that this issue is
a severe portability problem, some considered that the treatment
of interactive streams got involved in operating system issues
that were beyond the scope of the standard, so that part of the
text was removed.
∂08-Oct-88 2106 X3J13-mailer PRINT-CIRCLE-STRUCTURE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:06:50 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 21:01:23 PDT
Date: 8 Oct 88 21:01 PDT
Sender: masinter.pa@Xerox.COM
Subject: PRINT-CIRCLE-STRUCTURE (Version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-210123-2526@Xerox>
!
Issue: PRINT-CIRCLE-STRUCTURE
References: pp. 370-371
Category: CLARIFICATION
Edit history: Version 3, Masinter 10/8/88 (minor cleanup)
Version 2, Chris McConnell 10/05/88
Version 1, Chris McConnell 09/20/88
Problem description:
When a lisp object is printed that points to a structure with a user
defined print-function and there is a pointer back to the containing
object, the printer will recurse infinitely even when *print-circle*
is set to T. This prevents printing circular structures that point to
objects that cannot be printed and prevents the development of new
printed representations that can be read by the reader.
Proposal PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK:
When *print-circle* is T, a user defined print-function can print
objects to the supplied stream using WRITE, PRIN1, PRINC, or FORMAT
and expect circularities to be detected and printed using #n# syntax.
If a user defined print-function prints to a stream other than the one
that was supplied, then circularity detection starts over for that
stream.
Test Cases/Examples:
;;;
;;; Define a structure that can be circular and that has a slot with a
;;; value that cannot be printed.
;;;
(defstruct (TEST (:print-function print-test))
ptr
(function #'(lambda (x)
(error "No function is defined."))))
;;;
;;; This print function generates a machine readable printed
;;; representation for a structure with a slot that cannot be printed.
;;;
(defun PRINT-TEST (structure stream depth)
(format stream "#S(TEST PTR ~S)" (test-ptr structure)))
;;;
;;; Define two structures that point to each other. If this
;;; expression successfully evaluates at the top level, then the
;;; printed result should look like:
;;; #1=#S(TEST PTR #S(TEST PTR #1#))
;;;
;;; If it does not work then it will generate an infinite printed
;;; representation.
(setf *print-circle* t
*a (make-test)
*b (make-test)
(test-ptr *a) *b
(test-ptr *b) *a)
Rationale:
Many structures are circular and point to complex data structures that
may include things like closures that cannot be printed. It should be
possible to define a way to print these data structures such that they
can be read back in. Common LISP provides two mechanisms for these
problems (*print-circle* and the :print-function option to defstruct),
but they do not currently work together in most implementations.
Current practice:
Lucid 3.0 and the Genera do work on the test case. (Previous versions
did not.) KCL, Coral and Franz do not work.
Cost to Implementors:
Lucid and Symbolics have done it, so they could give an idea of the
difficulty. Possible techniques include passing the printer state
information by dynamic binding rather than by explicit parameters or
by supplying an internal stream to the user print function.
Cost to Users: None
Cost of non-adoption:
Currently this problem causes an infinite recursion whenever a user
print-function prints a lisp object that contains the structure that
is being printed by the user print function. If nothing is done, this
error will remain and the whole effort to provide a portable printed
representation of LISP structures is of minimal usefulness. In almost
any real application, there are circular structures with non printable
objects such as closures and hash tables that need to be printed. In
addition the development of printers for new reader macros becomes
much more of an effort then it should be since it requires
reimplementing the complete circularity detection mechanism.
Benefits:
If the proposal is adopted, then it becomes easier to define new
printed representations that are compact and that still capture the
information needed to rebuild data structure instances. It allows a
printed representation to hide the actual details of how a data
structure is implemented in terms of underlying LISP data structures.
Esthetics:
This proposal increases the uniformity of the language by making
*print-circle* work in all cases including where a user has defined a
new print function.
Discussion:
At least three members of the cleanup committee read this and think
it looks good.
∂08-Oct-88 2112 X3J13-mailer DRAFT Issue: PROCLAIM-LEXICAL (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:11:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 21:06:34 PDT
Date: 8 Oct 88 21:06 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: PROCLAIM-LEXICAL (Version 8)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-210634-2532@Xerox>
We're still working on this one.
!
Status: DRAFT
Issue: PROCLAIM-LEXICAL
References: variables (p55), scope/extent (p37), global variables (p68),
declaration specifiers (p157)
Category: CLARIFICATION/ADDITION
Edit history: Version 2 by Rees 28-Apr-87
Version 3 by Moon 16-May-87
Version 4 by Masinter 27-Oct-87
Version 5 by Masinter 14-Nov-87
Version 6 by Pitman 15-Sep-88
(major revision, for review by Jonathan Rees and Jeff Dalton)
Version 7 by Pitman 24-Sep-88
(minor revisions based on comments from Rees and Dalton)
Version 8 by Pitman 06-Oct-88 (merge recent discussion)
Status: For Internal Discussion
Problem Description:
Although local variables in Common Lisp may be `special' or `lexical,'
global variables (with the exception of named constants) may currently
only be `special.'
The Scheme language permits free variable references to refer to global
bindings. Their experience suggests that such usage would be useful to
the Common Lisp community. The absence of such a facility in Common Lisp
is a barrier both culturally (to the sharing of ideas) and technically
(to the sharing of code).
SPECIAL proclamations are uncontrollably pervasive. There is no way
to locally override or globally undo a SPECIAL proclamation.
Background/Analysis:
Variable evaluation may be viewed in Common Lisp as a search through
a set of environments to find a binding, and then the dereferencing of
that binding. The environments with which Common Lisp deals are
Lexical (L), Dynamic (D), and Global (G).
A SPECIAL declaration for a variable amounts to a request that the
variable be resolved by searching first the Dynamic and then the Global
environment (DG).
As currently described in CLtL, lexical variable reference searches
only the Lexical environment (L).
Because undeclared free variables in the interpreter are implicitly
declared SPECIAL by most (perhaps all) implementations, this amounts
to a search of Lexical, Dynamic, and Global (LDG). However, the
accompanying warnings in many implementations make it clear that this
behavior is not intended to be taken seriously.
Constants are looked up solely in the Global environment (G). They
have other properties as well, of course.
In the Scheme language, the default lookup is first Lexical, then
Global (LG). Providing compatibility for Scheme code is, and more
generally for a Scheme working style is therefore difficult because
Common Lisp does not provide the LG search style.
The issue of whether a variable can be assigned is orthogonal.
The issue of whether a variable can be bound and, if it can be, which
environment is used for the new binding is orthogonal.
Proposal (PROCLAIM-LEXICAL:LG):
Provide a new declaration (and proclamation) called LEXICAL which does
LG lookup. That is, variables declared LEXICAL would be looked up first
in the lexical environment (L) and then in the global environment (G)
if not found in the lexical.
Clarify that dynamic binding does DG lookup. That is, variables
declared SPECIAL would be looked up first in the dynamic
environment (D) and then in the global environment (G) if not found
in the lexical. Further clarify that SYMBOL-VALUE does DG lookup.
Define that a dynamic binding of a variable creates a new binding
in the dynamic environment (D) leaving the global environment (G)
unaffected.
Define that a lexical binding of a variable creates a new binding
in the lexical environment (L), leaving the global environment (G)
unaffected.
Note that an assignment to a variable which is bound in the global
environment (G) will affect lexical (LG) lookups for which there is
no lexical (L) binding and dynamic (DG) lookups for which there is
no dynamic (D) binding.
Note that these restrictions describe an abstract model, not a
concrete implementation. An implementation may still choose to
implement dynamic binding as either deep or shallow, but some
searching may be necessary to find the global cell in shallow bound
implementations [unless dynamic binding has been forbidden for
that variable].
Like SPECIAL declarations (and unlike type declarations),
compilers and interpreters would be required to notice and
respect this declaration.
Test Case:
#1: (proclaim '(lexical x))
(setq x 1)
(defun f (fn) (list x (funcall fn)))
(defun g (fn)
(let ((x 2))
(declare (special x))
(funcall fn #'(lambda () x))))
(g #'f) => (1 2)
#2: ; Warning: It is unlikely that any serious program would
; be written in so obscure a manner as this example.
; This just tests the fringe cases.
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
If the results of this example confuse you, keep in mind
that the results of code like this would be somewhat
confusing no matter what the chosen semantics because the
code itself is far from perspicuous.
An explanation of this behavior, which some people find less
than intuitive because of the bizarre choice of constructs:
X gets bound lexically to 3 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 4 because Y is [pervasively]
proclaimed SPECIAL.
Reference style for name X is changed to SPECIAL, making
lexical X=3 invisible.
Reference style for name Y is changed to LEXICAL, making
dynamic Y=4 invisible.
Global X=1 and global Y=2 are first two elements of list.
X gets bound lexically to 5 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 6 because Y is [pervasively]
proclaimed SPECIAL.
Closure is returned, capturing [lexical] X=5 but not
[special] Y=6.
Dynamic binding of Y to 6 disappears, dynamic binding
of Y to 4 reverts.
Closure is funcalled, returning captured X=5 and dynamically
active Y=4 in a list which becomes third list element.
Rationale:
This mechanism provides a simple and straightforward answer to
the problems stated above.
Current Practice:
Probably no one implements this.
Cost to Implementors:
A fair amount compiler work would probably be needed. Some compilers
may have hooks for most of this already laying around, but some may not.
Note well that this proposal does not require separate global lexical
and dynamic cells, so the data storage layout of Lisp need not change.
Moon says...
I have now thought of an efficient way to do this on Lisp machines,
using invisible pointers, and another efficient way to do it on
stock hardware, using one extra instruction on every global
reference of one or the other sort, plus a few extra instructions
in SPECIAL binding and unbinding. Given that, I no longer object
to the proposal as unimplementable.
It doesn't just require a few compiler changes, it requires some
reimplementation of the representation of global variables, with
concomitant changes to the compiler, the loader, the interpreter,
and probably the debugger. Every symbol now potentially has two
values accessible from the interpreter (the current SPECIAL and
the global LEXICAL) and you need the corresponding new data
structure to keep track of that.
Rees suggests...
In shallow-bound implementations, implementors may have to add a
small run-time routine that searches the dynamic saved-binding
stack to look for the global value in the case where the variable
has been dynamically bound. One might want a bit (or a count)
somewhere (perhaps in the symbol itself) to speed up the common
case of access to a global binding of a variable that hasn't been
dynamically bound; without some kind of optimization, you have to
search the whole saved-binding stack on every reference to a
free [lexical] variable.
While naively you might think you'd incur the cost of clearing the
valid bit on every dynamic binding (not acceptable), in actuality
the bit is a static property of programs (PROGV excepted). So the
only places you ever need to clear FOO's valid bit are in PROGV,
in the interpreter, and when FASLOADing code that contains a compiled
dynamic binding of FOO.
Cost to Users:
For the most part, this change is upward compatible.
Some code-walking tools would have to change.
Cost of Non-Adoption:
It would continue to be difficult to share code with Scheme.
New CL users coming from the Scheme community would be confused by
their sometimes inability to map what they know about variable binding
into the CL model of variable binding.
Some interesting native CL applications would be impossible to write
in a syntactically convenient style.
Benefits:
Enhanced flexibility of expression.
Rationalization of the semantics of dynamic variables.
Aesthetics:
Improved appeal to a certain sector of the programming community.
Discussion:
Rees points that it is an oversimplification to describe Scheme's
binding simply as LG since they have no Dynamic environment and
there is no way to distinguish LG and LDG. However, the reasons he
prefers LG are:
1. It's nice for readability and understandability to have a
declaration which tells you that a variable will not be
dynamically bound.
2. It's nice for performance in deep-bound implementations to have a
declaration that says that no search will be needed.
Of course, he notes, there could be a counter-argument to item 2
(in favor of LDG) in order to prefer shallow bound implementations,
but that still would not defeat the argument in item 1. Rees believes
that LG is slightly preferrable, but that LDG would be essentially
adequate for most of his needs.
Pitman supports PROCLAIM-LEXICAL:LG and believes that giving LDG the
name LEXICAL would be a serious mistake, leaving open the door for
program bugs due to accidental binding of variables presumed by the
programmer not to be bound. If someone (Moon?) seriously wanted LDG
type variables in addition to LG variables (under a name other than
LEXICAL), Pitman would not object.
Dalton expressed support for PROCLAIM-LEXICAL:LG (Version 6).
He observes that another reason for opposing LDG is that it suggests
the possibility that someone might want DLG. LG is simpler and still
accomplishes the stated purpose. He adds ``I would like to be able
to explain the global environment as a sort of giant, extensible
LET abound everything. This proposal seems to get fairly close.''
It would be possible to submit a proposal for a GLOBAL (G) declaration
under separate cover if anyone (Xerox?) was interested. Pitman thinks
this would be an interesting idea. Dalton points out, however, that
already with this proposal there is enough power to at least deal with
globals -- albeit circuitously. For example, to reference a global
variable X, one could write subroutines such as:
(defun global-x () (declare (lexical x)) x)
(defun set-global-x (value) (declare (lexical x)) (setq x value))
Eg, consider:
(defun f (x) (+ (global-x) x))
In principle, we could imaging saying that free variables should be
lexical by default, but that would only reduce error checking to no
good end. To be really useful, this proposal will need to be followed
by a proposal for primitives analogous to DEFVAR and/or DEFPARAMETER
but for lexical variables. However, since arguments over syntax are
likely to have plenty of issues of their own, we've separated this
proposal for primitive functionality from issues of syntax which
can be dealt with separately once this is passed.
Moon expressed concerns about the efficiency issues but after
thinking about it for a while convinced himself that this is
efficiently implementable both on stock and special purpose hardware.
JonL expressed concerns about the last-minute nature of this change,
which he sees as untested.
Dalton suggests that an alternative solution to the speed issue
might be possible to obtain by restricting a particular variable to
be either LEXICAL or SPECIAL but not both.
Dalton points that even if people don't like the details here, there
must be a better fallback solution than "do nothing". Pitman agrees
heartily.
----- End Forwarded Messages -----
∂08-Oct-88 2134 X3J13-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:34:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:30:41 PDT
Date: 8 Oct 88 21:30 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-213041-2554@Xerox>
!
Issue: REQUIRE-PATHNAME-DEFAULTS
References: *MODULES*, PROVIDE, REQUIRE, pp 188-191
LOAD, pp 426-427
Category: CHANGE
Edit history: Version 1 by Pierson 9/13/88
Version 2 by Pierson 9/19/88, change PROVIDE stuff per comments
Problem description:
PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences. These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.
The instructions on CLtL pp. 189-191 on the placement of PROVIDE and
REQUIRE don't work because they ignore interactions with LOAD. If
PROVIDE is placed at the head of a file which fails to load correctly,
the module will be incorrectly recorded as loaded. If PROVIDE is
placed at the end of the file, as is the unofficial current practice
in some groups, it is not possible to REQUIRE a file that REQUIREs the
current file; thus mutually dependent modules cannot be correctly
defined.
Proposal (REQUIRE-PATHNAME-DEFAULTS:DECLARATIVE):
Remove the second argument from REQUIRE. Change the description of
REQUIRE to:
The REQUIRE function tests whether a module is already present
(using a case-sensitive comparison); if the module is not present,
REQUIRE signals a correctable error of type REQUIRE-ERROR. The
error can be corrected by loading the appropriate file(s).
Note that there is no requirement that a module consist of exactly one
file.
Change the description of PROVIDE to:
"The PROVIDE function adds a new module name to the list of
modules maintained in the variable *MODULES* and possibly performs
other implementation-dependant actions to indicate that the module
in question has been loaded."
(There is no need to make a corresponding change to the definition of
REQUIRE, because it doesn't mention *MODULES*.)
Add a new second paragraph to the section on LOAD (CLtL 23.4):
"Top level PROVIDE functions in files being loaded are handled
specially. The PROVIDE is executed in a temporary environment
such that the module will appear to have been loaded during the
remainder of the load of the current file and any files loaded,
whether directly or by REQUIRE, during the loading of the current
file. If an error occurs during the loading of the current file,
all modules PROVIDEd during the load of the current file will be
forgotten. Otherwise, all these modules will be "confirmed" at
this level of nested loading. (Note that an implementation which
uses *MODULES* as the only loaded module database can support all
of this by simply rebinding *MODULES* appropriately internally
and pushing the new modules onto the old binding at the end.)"
Test Cases/Examples:
(REQUIRE 'fft)
Would still be legal.
(REQUIRE 'fft "fft")
Would no longer be Common Lisp.
Rationale:
The file loading feature of REQUIRE is non-portable. Since we can't
figure out an acceptable portable solution, the feature should be
flushed. Making REQUIRE signal a correctable error gives the user an
easy out in interactive situations.
Current practice:
All implementations that I know of currently support a second argument
to REQUIRE. Lucid and KCL use the second argment at the pathname to
load relative to the current working directory.
Cost to Implementors:
All currently conforming implementations will have to make a small
change.
Cost to Users:
Any (non-portable) user programs that rely on the current behaviour of
REQUIRE will have to change. On the other hand, porting Common Lisp
programs from one system to another may well be simplified because
REQUIRE errors will always correctable.
Cost of non-Adoption:
Part of the documented functionality of REQUIRE will continue to
unavailable to portable (and many non-portable) programs.
Benefits:
PROVIDE and REQUIRE will be clearly restricted to a portable,
checking role.
Aesthetics:
This simplifies the language by removing an environment-dependent
feature.
Discussion:
Pierson supports this proposal.
This proposal creates an asymmetry in the handling of *MODULES* that
may bother some people.
Several people would like to simply eliminate PROVIDE and REQUIRE from
the language and either leave this language space empty or provide a
portable DEFSYSTEM standard. Others believe that PROVIDE and REQUIRE
are useful as a safety-net even in the presence of DEFSYSTEM. This
proposal attempts to reduce PROVIDE and REQUIRE to a well-defined
safety-net and leaves the question of DEFSYSTEM to a separate
proposal (which I don't intend to write).
∂08-Oct-88 2146 X3J13-mailer Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:45:52 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:40:35 PDT
Date: 8 Oct 88 21:40 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-214035-2555@Xerox>
!
Issue: ROOM-DEFAULT-ARGUMENT
References: ROOM (p442)
Category: ADDITION
Edit history: 12-Sep-88, Version 1 by Pitman
Problem Description:
Passing no argument to ROOM is not equivalent to any argument which
can be passed. This makes data-flow from another function which wants
to call ROOM inconvenient. Rather than simply passing a value through,
the correct calling sequence must be selected as well. For example,
one might have to do something like
(CASE FLAG
(:DEFAULT (ROOM))
((T NIL) (ROOM FLAG)))
where (ROOM FLAG) would suffice
Proposal (ROOM-DEFAULT-ARGUMENT:NEW-VALUE):
Specify that passing an argument of :DEFAULT is equivalent to passing
no argument to ROOM.
Test Case:
(ROOM ':DEFAULT) is functionally equivalent to (ROOM).
Rationale:
Minimal change needed to get around the stated problem.
Allows ROOM to be describable without reference to supplied-p
information.
Current Practice:
Symbolics Genera defines ROOM using &REST and looks for NIL, (T), or (NIL).
[This reduces its ability to do compile-time number-of-argument checking.]
Some other implementations probably have a magic undocumented value
to avoid use of a SUPPLIED-P argument.
Cost to Implementors:
Probably it involves negligible resources to change this.
In most implementations, the resulting code would probably look better.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
The description of ROOM will look yucky in the emerging specification.
The source code for ROOM will look yucky.
[How's that for objective? -kmp]
Error checking in some implementations may be sub-optimal.
Benefits:
The description of ROOM in the now-being-written specification would
be less complicated.
Aesthetics:
This proposal would make a minor improvement in aesthetics.
Discussion:
This is obviously a low-priority issue, but would require such little
resources to fix that it seems worth doing.
Pitman supports this addition.
It's perhaps too bad that keywords like :SHORT, :MEDIUM, and :LONG
weren't chosen instead of T and NIL, since T and NIL have a bit of a
binary feel to them and it's hard to think of a good name for the
default case.
∂08-Oct-88 2129 X3J13-mailer DRAFT Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:29:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:24:26 PDT
Date: 8 Oct 88 21:24 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-212426-2546@Xerox>
There were at least 20 messages after this draft was circulated
among the cleanup committee; the discussion is too long to append
and there is currently no summary of it. However, this issue
was last raised in November 1987; perhaps some resolution will
be more forthcoming.
!
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
DELETE-IF-NOT, DELETE-DUPLICATES, NSUBSTITUTE,
NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT (pp254-256); NCONC,
NRECONC (p269); NBUTLAST (p271); NSUBST, NSUBST-IF,
NSUBST-IF-NOT (p274); NUNION, NINTERSECTION,
NSET-EXCLUSIVE-OR (pp276-279).
Category: CLARIFICATION
Edit history: 11-Feb-87, Version 1 by DLA@Stony-Brook.SCRC.Symbolics.COM,
29-Oct-87, Version 2 by Pitman (flesh out proposals)
Status: For Internal Discussion
Problem Description:
Currently, the exact nature of the side-effect performed by list
modification routines is not specified.
Test Cases:
For GETF...
(SETQ FOO (LIST 'A 'B 'C 'D 'E 'F)) ==> (A B C D E F)
(SETQ BAR (CDDR FOO)) ==> (C D E F)
(REMF FOO 'C)
BAR ==> ??
In Symbolics Common Lisp, BAR holds (C D E F).
CLtL allows other interpretations. eg, BAR might hold
(C), (NIL), (C NIL) or (C D).
In MAKE-EXPLICITLY-DEFINED, BAR would hold (C D E F).
In MAKE-EXPLICITLY-VAGUE, any of these interpretations (and
others as well) would still be valid
For DELETE...
(SETQ FOO (LIST 'A 'B 'C)) ==> (A B C)
(SETQ BAR (CDR FOO)) ==> (B C)
(SETQ FOO (DELETE 'B FOO)) ==> (A C)
BAR ==> ??
(EQ (CDR FOO) (CAR BAR)) ==> ??
In Symbolics Common Lisp, these last two expressions return ((C)) and T.
In MAKE-EXPLICITLY-DEFINED, they would return (B C) and NIL.
In MAKE-EXPLICITLY-VAGUE, either of these interpretations (and others
as well) would be valid.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-DEFINED):
Clarify that the destructive behavior of the following operators
is restricted as indicated. Note well -- only the side-effect behavior
of these functions is discussed here; these remarks are not intended
as complete functional descriptions.
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF the CADR of what
(GET-PROPERTIES place (LIST indicator)) would return.
(REMF place indicator)
is permitted to either SETF place or to SETF the CDR of the
part of the top-level list in place which points to what
(GET-PROPERTIES place (LIST indicator)) would return.
In particular, the two removed cells may not be destructively
modified.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list is permitted to setf the CDR of any
subtail of sequence to point to any other subtail of sequence,
to NIL, or to any piece of newly created list structure.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list is permitted to SETF the CDR of any part
of that list which points to a tail whose car is object.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-IF-NOT test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (NOT (FUNCALL test ITEM)))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list is permitted to SETF the CDR of any part
of that list which points to a duplicated element that is to be
removed.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
(NSUBSTITUTE-IF-NOT new-object test sequence ...)
when sequence is a list is permitted to SETF the CAR of any part
of that list which must be replaced by NEW-OBJECT.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is permitted to SETF the CDR of the LAST of any of its argument
lists which are non-null, except the last argument.
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NBUTLAST list ...)
is permitted to SETF the tail of its argument list whose CDR
is LAST of that argument LIST.
(NSUBST new-object old-object tree)
(NSUBST-IF new-object test tree)
(NSUBST-IF-NOT new-object test tree)
is permitted to SETF any part of the TREE of conses which must
be replaced by NEW-OBJECT.
Note, however, that since the tree might be a degenerate tree
containing no conses and since the side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to setf the CDR of any subtail of either list to point
to any other subtail of either list, to NIL, or to any piece of newly
created list structure.
Rationale:
This implements what some users will consider the status quo.
In most cases, it is consistent with what naive implementations of
these functions might do.
Benefits:
By being more explicit about the side-effects which can be expected,
users can write programs which more reliably exploit these side-effects.
In some case, this may make certain programming problems easier.
Certain naive user assumptions and assumptions based on the behavior
of older lisp dialects would be supported.
Compatibility with older Lisp dialects (eg, Zetalisp, Maclisp, ...)
would generally be better.
Gratuitious porting hassles would be naturally lessened slightly.
In situations where programmers inadvertently depended upon the specific
nature of a particular operator's side-effect, chances would be much
greater that the code would be portable because there would be less room
for implementations to vary.
Non-Benefits:
Implementations may be forced to be less efficient than they could be
if the MAKE-EXPLICITLY-VAGUE proposal were adopted, since that proposal
allows implementors more room for optimization. Some existing
implementations will be forced to become less efficient to meet the
standard, degrading performance of existing applications which do not
rely on the new features with no benefit to those existing applications.
Adoption Cost:
Some implementations would have to change. For example, Symbolics Common
Lisp makes more unusual assumptions about what it can modify than some
of the above rules allow.
Conversion Cost:
Probably none. Users must currently tread lightly since they really
have no idea in many cases what kind of side-effect is really likely to
occur when they use some of the existing destructive operators.
Some implementations might be forced to change, and since some user
programs might have depended on the old behavior, programs which used
to run might be broken in the transition. However, in most cases where
an implementation guarantees any behavior, it is likely to be the one
suggested here. Systems which have other behaviors are likely to warn
users not to depend on the specifics of those behaviors. So the incidence
of problems arising in practice is likely to be very small, though
probably not nonzero.
Aesthetics:
Some of these restrictions tend to expose more detail about the
implementation of these operators, turning them from abstract operations
into more concrete utilities. This is probably an issue that can be
addressed by appropriate information hiding in a User's Manual however.
No matter how unpleasant the presence of these somewhat concrete
restrictions may seem, the porting bugs which arise in their absence are
bound to seem more unpleasant to some users.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-VAGUE):
Clarify that the destructive behavior of the following operators
is restricted as indicated:
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-IF-NOT test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (NOT (FUNCALL test ITEM)))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
(NSUBSTITUTE-IF-NOT new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists (except the last, which is not required to
be a list and must not be modified).
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NBUTLAST list ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given list.
(NSUBST new-object old-object tree)
(NSUBST-IF new-object test tree)
(NSUBST-IF-NOT new-object test tree)
is permitted to SETF any part of the TREE of conses which must
be replaced by NEW-OBJECT.
Note, however, that since the tree might be a degenerate tree
containing no conses and since the side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists.
Rationale:
This is probably the status quo from a typical implementor's point of view.
Benefits:
Users would be discouraged from taking advantage of subtle details
of these destructive operations because such details would be explicitly
not guaranteed to be portable.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion. For example, in Symbolics systems,
DELETE of a cdr-coded list could use the implementation primitive
%CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
pointers.
Garbage collection effectiveness can also be improved. For example,
all of the destructive operations which remove objects (eg, REMF)
could remove CAR pointers to removed objects which are more volatile
than the list itself, assisting the garbage collector and thereby
improving memory usage and paging performance.
Non-Benefits:
Users who inadvertently depend on side-effect behavior may be rudely
surprised when moving between implementations.
Compatibility with older Lisp dialects is diminished.
Adoption Cost:
None. This is the status quo for implementors.
Conversion Cost:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are already in such danger, and this change to the documentation would
just publicize it. The clarification would -encourage- good programming
practice by warning people to only obey the published contract of the
above-mentioned functions.
There is, however, no automatic technique for making this check for
programs already in error. Bugs due to unexpected side-effects are in
general among the hardest to reckon with.
Aesthetics:
Most of these functions implement abstract operations. For example,
REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
Discussion:
Conversation on the Common-Lisp mailing list has made it clear that
the current situation is not good because it does not make the designers'
intent clear. The list modification allowed should either be specified,
or explicitly documented as unspecified and up to the individual
implementation. If the list modification is specified, then programmers
can rely on the specification. If it is unspecified, then implementors
can take advantage of that to make their implementation more efficient.
Pitman believes that REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-VAGUE
may be better from a purist point of view, but strongly supports
REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-DEFINED
because of practical considerations related to reliably being able to
debug portable code, a stated priority of an ``industrial strength''
language such as Common Lisp. The more alike implementations are forced
to be, the better the chances that something that ran one place will run
another.
DLA, who raised this issue, disagrees strongly. He cites efficiency
and does not believe performance should be traded off for features
which reasonable code does not tend to use. Metering in Symbolics test
systems have shown that there are performance gains to be had by
allowing implementations flexibility in these areas. DLA believes that
if users want more predictability from these functions, they should
write private variants that implement whatever predictability they
require. Additionally, he argues that the implementation users expect
is not obviously the one chosen in MAKE-EXPLICITLY-DEFINED. For
example, many programmers have used NREVERSE for years and assumed that
it shuffled list elements rather than CDRs.
DLA points out that MAKE-EXPLICITLY-DEFINED is still lax enough that if
FOO holds (A B) and you do (SETF (GETF FOO 'A) 'C), FOO could be
(A C A B). We should be sure this doesn't get left vague if that
proposal is adopted.
----- End Forwarded Messages -----
∂08-Oct-88 2159 X3J13-mailer DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:59:47 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:58:06 PDT
Date: 8 Oct 88 21:58 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-215806-2579@Xerox>
!
Issue: SYMBOL-MACROLET-DECLARE
References: SYMBOL-MACROLET (88-002R page 2-81)
WITH-ACCESSORS (88-002R page 2-88)
WITH-SLOTS (88-002R page 2-92)
Category: ADDITION
Edit history: Version 1, 12-Sep-88, Moon
Problem description:
It would be both natural and nice to be able to write
(with-slots (rho theta) point
(declare (single-float rho theta))
...computation...)
Proposal (SYMBOL-MACROLET-DECLARE:ALLOW):
Allow declarations at the head of the body of SYMBOL-MACROLET, and hence
in WITH-ACCESSORS and WITH-SLOTS. Exactly the same declarations are
allowed as for LET, with one exception: SYMBOL-MACROLET signals an error
if a SPECIAL declaration names one of the symbols being defined as a
symbol-macrolet. A type declaration of one of these symbols is equivalent
to wrapping a THE expression around the expansion of that symbol.
Test Cases/Examples:
See problem description.
Rationale:
If SYMBOL-MACROLET is intended to resemble LET in syntax, it ought to
allow declarations. When writing a SYMBOL-MACROLET directly, the user
could just as easily write a THE expression instead of a type
declaration. However, when invoking a macro such as WITH-SLOTS that
expands into SYMBOL-MACROLET, the user does not have this option since
the expansion is not supplied explicitly by the user.
Current practice:
SYMBOL-MACROLET was only tentatively added to Common Lisp 3 months ago.
Cost to Implementors:
Less than one man-hour.
Cost to Users:
None.
Cost of non-adoption:
Minor wart in the language.
Benefits:
More consistent language definition.
Esthetics:
More consistent language definition.
Discussion:
None.
----- End Forwarded Messages -----
∂08-Oct-88 2203 X3J13-mailer DRAFT Issue SYMBOL-MACROLET-SEMANTICS, Version 4
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 22:03:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 22:00:34 PDT
Date: 8 Oct 88 22:00 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue SYMBOL-MACROLET-SEMANTICS, Version 4
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-220034-2580@Xerox>
This is DRAFT because of some confusion over the handling
of SETQ of symbol-macros.
!
Issue: SYMBOL-MACROLET-SEMANTICS
References: X3J13 document 88-002R, Chapter 2, pp. 2-81f.
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
22-September-88, Version 3 by Piazza
22-September-88, Version 4 by Piazza
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion in the same lexical environment as the
symbol macro invocation, exactly analogous to normal macros.
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Also, Pitman points out that, rather than extending the existing
MACROEXPAND and MACROEXPAND-1 functions, new functions could be introduced
to expand symbol macros. However, there seems to be no particular reason
to do this.
----- End Forwarded Messages -----
∂08-Oct-88 2211 X3J13-mailer DRAFT Issue: TAILP-NIL (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 22:11:11 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 22:07:06 PDT
Date: 8 Oct 88 22:07 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: TAILP-NIL (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-220706-2582@Xerox>
!
Issue: TAILP-NIL
References: TAILP (p275)
Category: CLARIFICATION/CHANGE
Edit History: 13-Sep-88, version 1 by Walter van Roggen,
13-Sep-88, version 2 by Pitman
Problem Description:
CLtL (p275) specifies TAILP as:
TAILP sublist list [Function]
This predicate is true if SUBLIST is a sublist of LIST (i.e.,
one of the conses that makes up LIST); otherwise, it is false.
Another way to look at this is that TAILP is true if
(NTHCDR n list) is SUBLIST, for some value of N. See LDIFF.
Two common implementations of this definition are:
(defun tailp (sublist list) ;Definition "A"
(do ((list list (cdr list)))
((endp list) nil)
(if (eq sublist list)
(return t))))
(defun tailp (sublist list) ;Definition "B"
(do ((list list (cdr list)))
((atom list) (eq list sublist))
(if (eq sublist list)
(return t))))
They differ only in their treatment of the atomic case.
At issue is the fact that () is a list, and hence some would
argue that it is a sublist of all other lists. On the other hand,
the definition of TAILP seems to imply that being a cons is a
necessary precondition of being a "sublist".
Proposal (TAILP-NIL:NIL):
Clarify that the sublist argument to TAILP must be a list
and that (TAILP NIL X) returns NIL for all lists X.
Qualify the description in CLtL by saying that (TAILP sublist list)
is true if SUBLIST is a cons and (NTHCDR n list) is SUBLIST for
some value of N, and is false otherwise.
Rationale:
This is the status quo in a number of implementations.
Proposal (TAILP-NIL:T):
Strike any text in the definition of TAILP which suggests that a
sublist must be a cons.
Clarify that (TAILP any-atom list) returns T iff (NTHCDR n list) is
SUBLIST for some value of N, and false otherwise.
Rationale:
This is more consistent with the definition of LDIFF, which
gives a useful meaning to arbitrary atomic SUBLIST arguments.
This gives a more elegant definition of SUBLIST, allowing it to
refer to any list -- including the empty list -- which is a
part of another list.
Test Cases:
#1: (LET ((X '(B C))) (TAILP X (CONS 'A X)))
should return T in all implementations.
#2: (TAILP '(X Y) '(A B C))
should return NIL in all implementations.
#3: (TAILP '() '(A B C))
returns NIL under proposal TAILP-NIL:NIL
returns T under proposal TAILP-NIL:T
#4: (TAILP 3 '(A B C))
is an error under proposal TAILP-NIL:NIL
returns NIL under proposal TAILP-NIL:T
#5: (TAILP 3 '(A B C . 3))
is an error under proposal TAILP-NIL:NIL
returns T under proposal TAILP-NIL:T
#6: (TAILP '(X Y) '(A B C . 3))
is an error under proposal TAILP-NIL:NIL
returns NIL under proposal TAILP-NIL:T
Current Practice:
Symbolics Genera is consistent with TAILP-NIL:T.
[Walter alleges TAILP-NIL:NIL is what all implementations already
do, but since Genera is not in conformance, KMP regards that
hypothesis as suspect. We need real data points, folks.]
Cost to Implementors:
An implementation of TAILP-NIL:NIL is given as Definition "A" in the
problem description.
An implementation of TAILP-NIL:T is given as Definition "B" in the
problem description.
Some implementations might have compiler optimizers for these definitions
as well, so a slight amount of additional effort might be required.
Cost to Users:
Given that current practice varies widely on the disputed case,
this is unlikely to have a practical effect on existing portable code.
Benefits:
Either description makes the language more precise.
[Pitman believes that] TAILP-NIL:T is more consistent with the behavior
of TAILP and more consistent with what he thinks should be the
definition of a sublist.
Discussion:
This issue was first raised in ">GLS>clarifications.text" of 12/06/85.
Pitman supports TAILP-NIL:T.
----- End Forwarded Messages -----
∂08-Oct-88 2211 X3J13-mailer DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 22:11:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 22:07:11 PDT
Date: 8 Oct 88 22:07 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-220711-2583@Xerox>
!
Issue: TEST-NOT-IF-NOT
References: Functions offering a :TEST-NOT keyword:
ADJOIN (p276), ASSOC (p280), COUNT (p257), DELETE (p254),
DELETE-DUPLICATES (p254), FIND (p257),
INTERSECTION (p277), MEMBER (p275), MISMATCH (p257),
NINTERSECTION (p277), NSET-DIFFERENCE (p278),
NSET-EXCLUSIVE-OR (p278), NSUBLIS (p275), NSUBST (p274),
NSUBSTITUTE (p256), NUNION (p276), POSITION (p257),
RASSOC (p281), REMOVE (p253), REMOVE-DUPLICATES (p254),
SEARCH (p258), SET-DIFFERENCE (p278),
SET-EXCLUSIVE-OR (p278), SUBLIS (p274), SUBSETP (p279),
SUBST (p273), SUBSTITUTE (p255), TREE-EQUAL (p264),
UNION (p276);
Functions with "-IF-NOT" in their name:
ASSOC-IF-NOT (p280), COUNT-IF-NOT (p257),
DELETE-IF-NOT (p254), FIND-IF-NOT (p257),
MEMBER-IF-NOT (p275), NSUBST-IF-NOT (p274),
NSUBSTITUTE-IF-NOT (p256), POSITION-IF-NOT (p257),
RASSOC-IF-NOT (p281), REMOVE-IF-NOT (p253),
SUBST-IF-NOT (p273), SUBSTITUTE-IF-NOT (p255);
Issue FUNCTION-COMPOSITION
Category: CHANGE
Edit history: 02-Oct-88, Version 1 by Pitman (just FLUSH-ALL)
05-Oct-88, Version 2 by Pitman (add option FLUSH-TEST-NOT)
Status: For Internal Discussion
Problem Description:
The -IF-NOT functions are functionally unnecessary.
The :TEST-NOT keywords are not only functionally unnecessary but
also problematic because it's not clear what to do when both :TEST
and :TEST-NOT are provided.
Many people think Common Lisp is more `bloated' than it needs
to be and these aspects of the language are commonly cited
specific examples.
Proposal (TEST-NOT-IF-NOT:FLUSH-ALL):
Remove all -IF-NOT functions (named above) from Common Lisp.
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler.
The removal of :TEST-NOT also makes the language easier to explain.
Cost to Implementors:
Very slight.
Some symbols would disappear from the LISP package but could
still be offered in proprietary packages if deemed important
enough.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Proposal (TEST-NOT-IF-NOT:FLUSH-TEST-NOT):
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler and easier to explain.
Cost to Implementors:
Very slight.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Current Practice:
Presumably no one has done this yet.
Cost to Users:
Some rewrites would be needed.
Those rewrites, which are already fairly simple, would be even
more simple if some form of the FUNCTION-COMPOSITION issue is
voted in -- in particular, the COMPLEMENT function which it
proposes would help enormously in this regard.
Cost of Non-Adoption:
Common Lisp would continue to be what some people feel is
"bigger than it needs to be".
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Presumably this makes the language easier to teach.
Discussion:
Moon expressed reservations about FLUSH-ALL (in Version 1, where
FLUSH-TEST-NOT was not offered) because it was such an incompatible
change.
Steele (commenting on Version 1) noted that his main reservation to
FLUSH-ALL is that he uses REMOVE-IF-NOT much more than REMOVE-IF.
Pierson, Dalton and Pitman support the combination of
TEST-NOT-IF-NOT:FLUSH-ALL (and FUNCTION-COMPOSITION:NEW-FUNCTIONS)
in spite of the incompatible change because of the aesthetic appeal.
This issue is related to FUNCTION-COMPOSITION, but is not dependent
on it.
van Roggen points out that a long time ago, he suggested dropping
-IF-NOT and :TEST-NOT, adding a function such as COMPLEMENT, and
adding a #~ readmacro such that
(FIND-IF-NOT #'ZEROP '(0 0 3))
== (FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
== (FIND-IF #~ZEROP '(0 0 3))
Richard Mlynarik suggests that even the -IF functions provide
little extra use since
(xxx-IF test sequence ...)
can be rewritten
(xxx test sequence :test #'funcall).
He says he doesn't care what we do with this issue, however, since
he will just continue to use [MIT-style] LOOP in cases where these
sequence functions would seem to be called for.
----- End Forwarded Messages -----
∂08-Oct-88 2153 X3J13-mailer Issue: SETF-SUB-METHODS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:53:35 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:50:04 PDT
Date: 8 Oct 88 21:50 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: SETF-SUB-METHODS (Version 5)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-215004-2565@Xerox>
!
Issue: SETF-SUB-METHODS
References: CLtL pp. 95-96, 99, 105-106, 166
Issue: PUSH-EVALUATION-ORDER
Category: CLARIFICATION
Edit history: Version 1: JonL White & Ken D. Olum 12-Feb-88
(based on problem originally called SETF-METHOD-FOR-SYMBOLS)
Version 2: JonL White 23-May-88 (fix references and spellings).
Version 3: JonL White 25-May-88
Version 4: JonL White & Ken D. Olum 26-May-88 (final insights!)
Version 5: Masinter (respond to comments)
Problem description:
Implementations differ in the left-to-right order
of evaluation in the following form:
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
In some implementations, the side-effect of the setq appears to happen before
the evaluation of the place form (getf r 'b) which is necessary to fetch the
list being updated. A typical result is 'r' = (B 6), 's' = (A 1 B 2 C 3)
after the operation.
There is a similar problem with SETF's over LDB, MASK-FIELD, and CHAR-BIT.
CLtL p99 is explicit about left-to-right order of evaluation.
However, the specification is less clear about computations involved
in "evaluation" of the subforms, and other computations that are implicit
in the notion of "doing an access" or "doing a store".
Proposal: SETF-SUB-METHODS:DELAYED-ACCESS-STORES
This proposal specifies more explicilty the behavior of SETF in the case
of access forms whose sub-forms are permitted to be generalized variable
references [and which thus need to call GET-SETF-METHOD during setf macro
expansion].
Remember, first, that GET-SETF-METHOD returns the following:
-- Some temporary variables
-- A list of value-producing forms
-- A list of store-variables (normally one).
-- A storing form.
-- An accessing form.
The code produced as the macro expansion of a SETF form that
itself admits a generalized variable as an argument must essentially
do the following major steps:
** It evaluates the value-producing sub-forms, in left-to-right order, and
binds the temporary variables to them. This will be called "binding the
temporaries."
** It "reads the value" from the generalized variable using the supplied
accessing form, to get the "old value"; this will be called "doing the
access." [Note that this is done after all the evaluations of the
preceeding step, including any side-effects they may have.]
** It binds the store-variable to a new value, and then installs this
new value into the generalized variable using the supplied "storing
form". This will be called "doing the store."
"Reading the value" of a generalized variable reference is not part of
the series of evaluations that must be done in left-to-right order.
The place-specifier forms listed at the top of CLtL p96 permit admit (other)
place-specifiers as arguments; during the SETF expansion of these forms, it
is necessary to call GET-SETF-METHOD in order to figure out how the inner,
nested generalized variable must be treated. This proposal requires GETF be
listed among these forms, since it must have a sub-recursive <place> specifier
[however, there is no Common Lisp function serving as a pseudo-update function
for it, the way DPB serves for LDB].
For each place-specifier form with a sub-recursive place specifier,
the information from GET-SETF-METHOD is used as follows.
CHAR-BIT:
In a form such as:
(SETF (CHAR-BIT <place-form> <bit-name>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not to a character object itself.
Thus this SETF should generate code to do the following:
1. Bind the temporaries for <place-form>
2. Evaluate <bit-name> (and bind into a temporary)
3. Evaluate <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form>, with the given bit-name of the
character fetched in step 4 changed to reflect the value from step 3.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different "bit" of the character --
then the change of the bit denoted by <bit-name> will be to that altered
character, because the "access" step is done after the <value-form>
evaluation. See example 1 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
LDB:
In a form such as:
(SETF (LDB <byte-spec> <place-form>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not to any object of type integer.
Thus this SETF should generate code to do the following:
1. Evaluate <byte-spec> (and bind into a temporary)
2. Bind the temporaries for <place-form>
3. Evaluate <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form> with the given bit-field of the integer
fetched in step 4 replaced with the value from step 3.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different bit-field of the integer --
then the change of the bit-field denoted by <byte-spec> will be to that
altered integer, because the "access" step is done after the <value-form>
evaluation. See example 2 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
MASK-FIELD:
This case is the same as LDB in all essential aspects.
GETF:
In a form such as:
(SETF (GETF <place-form> <ind-form>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not necessarily to the particular list
which is the property list in question.
Thus this SETF should generate code to do the following:
1. Bind the temporaries for <place-form>
2. Evaluate <ind-form> (and bind into a temporary)
3. Evaluate the <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form> with a possibly-new property list
obtained by combining the values from steps 2, 3, and 4.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different named property in the list,
then the change of the property denoted by <ind-form> will be to that
altered list, because the "access" step is done after the <value-form>
evaluation. See example 7 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
Note that this phrase "possibly-new property list" treats the
implementation of property lists as a "black box" -- it can mean that
the former property list is somehow destructively re-used, or it can
mean partial or full copying of it. This is like the question of REMOVE
or DELETE -- do you copy or do you destructively alter. Since the answer
could go either way, the treatment of the resultant value for the
"possibly-new property list" must proceed as if it were a different copy
needing to be stored back into the generalized variable.
The "read-modify-write" macros such as INCF, DECF, PUSH, POP,
and REMF, as well as PSETF, SHIFTF, and ROTATEF should be
specified to have the same evalauation order for the subforms of
the "place" arguments; this would generally follow from their definition
in terms of SETF.
Test Cases:
1. (setq char (make-char #\A 1)) ==> #\Control-A
(rotatef (char-bit char :control)
(char-bit char :meta))
char ==> #\Meta-A
;; It's as if you start with #\Control-A, and then first turn the
;; :control bit off, because the :meta bit was originally off; and
;; then to the resulting #\A, you add the :meta bit since the
;; :control bit was originally on.
Note, however, that if an implementation doesn't support both of these
character 'bits', then this test case would have to be re-written to
reference two independent bits actually supported. If an implementation
supports fewer than two independent character bits, then this test case
is entirely moot.
2. (setq integer #x69) ==> #x69
(rotatef (ldb (byte 4 4) integer)
(ldb (byte 4 0) integer))
integer ==> #x96
;; This very-realistic example is simply trying to swap two
;; independent bit fields in an integer. Note that the generalized
;; variable of interest here is just the (possibly local) program
;; variable 'integer'.
3a.(setq l1 (setq l2 (list #x69))) ==> (#x69)
(setf (ldb (byte 4 4) (car l1))
(ldb (byte 4 0) (car (prog1 l1
(setq l1 nil)))))
l1 ==> nil
l2 ==> (#x99)
;; Note that the (setq l1 nil) didn't affect the actions of the setf
;; at all, since l1 was evaluated and its value was saved away in a
;; temporary variable as part of the step "2. Bind the temporaries
;; for <place-form>", and this was done before the evaluation of the
;; <value-form> which contains the (setq l1 nil). Note also that the
;; step "4. Do the access to <place-form>" means fetching the CAR of
;; the saved (temporary) value of 'l1'; it does not mean doing a LDB
;; on anything like that.
3b.(setq l1 (setq l2 (list #x69))) ==> (#x69)
(setf (ldb (byte 4 4) (car l1))
(ldb (byte 4 0) (car (rplaca l1 #x17))))
l1 ==> (#x77)
l2 ==> (#x77)
;; Note that the (rplaca l1 #x17) altered the contents of what l1
;; was pointing to. Thus even though l1 was evaluated and its
;; value was saved away in a temporary variable as part of the step
;; "2. Bind the temporaries for <place-form>", and even though this
;; was done before the evaluation of the <value-form> which contains
;; the rplaca, still the side-effect changes things because it alters
;; what will be fetched during the "do the access" step.
4. (setq integer #x69)
(setf (mask-field (byte 4 4) integer) (incf integer)) => #x6A
integer ==> #x6A
5. (setq integer #x6A)
(setf (mask-field (byte 4 4) integer) (ash (incf integer) 4)) => #x6B0
integer => #xBB
6. (setq s (setq r (list 'a 1 'b 2 'c 3))) ==> (a 1 b 2 c 3)
(setf (getf r 'b)
(progn (setq r nil) 6)) ==> 6
r ==> (b 6)
s ==> (a 1 b 2 c 3)
;; Note that the generalized variable of concern here is the (degenerate?)
;; one of simply the program variable 'r'; it is not a property-list
;; slot denoted by (getf r 'b). At the time the step "4. Do the access
;; to <place-form>" is performed, the evaluation of the <value-form>
;; has already altered the generalized variable 'r', and thus a nil is
;; returned for this access; that is why a fresh property-list (B 6) is
;; created an stored back into 'r'.
7. (setq s (setq r (list (list 'a 1 'b 2 'c 3)))) ==> ((a 1 b 2 c 3))
(setf (getf (car r) 'b)
(progn (setq r nil) 6)) ==> 6
r ==> nil
s ==> ((A 1 B 6 C 3))
;; Note that the (setq r nil) does not affect the actions of the setf
;; because the value of R had already been saved in a temporary variable
;; as part of the step "1. Bind the temporaries for <place-form>". Only
;; the CAR of this value will be accessed, and subsequently modified
;; after the value computation.
Rationale:
As a principle,
(setf (foo-a x) (progn (setf (foo-b x) ...)
new-a-value))
should always set both of the "slots" of 'x', even if these slots are
implemented as bit-fields, getf-properties, and so on. Only by separating
out evaluation from "generalized variable access", and by specifying that
the access is done after all the evaluations, can this correctly be done.
Current Practice:
Lucid Common Lisp already operates pretty much according to this proposal.
Symbolics Genera 7.2 foolishly adopted an earlier proposal
(SETF-METHOD-FOR-SYMBOLS) before it was officially approved by X3J13 and
its parent standards organization. This proposal is incompatible with
that one, so Genera 7.2 does not implement the behavior described here,
and fails test cases 1, 2, 4, 5, and 6. Symbolics Genera 7.1
is probably closer to this proposal.
Performance impact:
Small. This proposal might slow down macro-expansion slightly,
might cause some current optimizations not to work as well. However,
the net effect is likely negligible.
Cost to Implementors:
In some implementations, this would require a careful revisiting of
the handling of SETF and generalized variable modifiers.
Cost to Users:
Small; although this will impose an incompatible change on
implementations that don't behave as proposed, and might have
an effect on (non-portable) code, we believe the effects
are not widespread.
Cost of non-adoption:
SETF left-to-right order of evaluation will not be well specified;
implementations will differ for no good reason.
Benefits:
Uniform semantics and portability in the face of recursive "place specifiers"
for SETF. Setf of (LDB ... <place>) and of (GETF <place> ...) will behave
uniformly no matter the nature of the <place>.
Anyone who has copied examples from p105 and p106 will continue to
be able to use them.
Esthetics:
See "Cost of non-adoption"
Discussion:
This is a difficult proposal to specify.
In the detailed descriptions for each access form, the phrase
"the place referred to by the <place-form> must always be both
accessed and updated; note that the update is to the generalized
variable specified by <place-form>"
is not intended to prevent optimizations that could occur when the
code "knows" that the new value will be EQ to the old one. The only
requirements is that the results be semantically equivalent.
There is an interesting parallel between this case for GETF and the
very common mistake made by Lisp programmers with respect to the
function DELETE. How often the complaint is filed that DELETE didn't
do anything when it should have; but in fact the filer simply forgot
that delete, although permitted to destructively modify the original
list, may also return some tail of the list originally give it,
whether or not an alteration occurs.
(setq l '(a a b c d)) ==> (a a b c d)
(delete 'a l) ==> (b c d)
l ==> (a a b c d)
The unwary user thinks that because 'l' is still EQ to the original value
that "DELETE didn't do anything". The temptation to ignore the resultant
value of DELETE parallels the temptation to forget about a need to perform
a final update to <place-form> in the setf-of-getf case.
In the (degenerate?) case when a generalized variable
is in fact simply a program variable, then there are no sub-forms to be
considered "value-producing" forms; in fact, "doing the access" for such
a generalized variable (i.e. a program variable) is functionally the
same as evaluating it. This explains why the behaviour in the "Problem
Description" is at first perplexing -- the "do the access" step has the same
semantics as an evaluation step, even though it is done after all the
prescribed evaluations.
The issue PUSH-EVALUATION-ORDER is a clarification about just the point
of the evaluation order for the various subforms to a PUSH; thus there
is a similarity to this issue, but the present issue has a much deeper
problem because of the need to call GET-SETF-METHOD during setf macro
expansion.
∂08-Oct-88 2159 X3J13-mailer DRAFT Issue: STREAM-INFO (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:59:37 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:55:17 PDT
Date: 8 Oct 88 21:55 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: STREAM-INFO (Version 5)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-215517-2573@Xerox>
This issue has some interactions with the character proposal.
There has been a recommendation (from me) that the functions
be allowed to return/accept non-complex numbers rather than
integers where possible, given the possibilities of output
streams that can do arbitrary scaling.
Perhaps this issue should have been called
PRETTY-PRINT-WIDTH-SUPPORT
!
Status: DRAFT
Issue: STREAM-INFO
References: FORMAT ~T (pp398-9) and ~<...~> (pp404-6), PPRINT (p383)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman (2d model)
23-Jun-88, Version 2 by Waters (1d model, modified 2d model)
24-Jun-88, Version 3 by Pitman (minor reformatting)
24-Jun-88, Version 4 by Pitman (remove 2d model for submission)
23-Sep-88, Version 5 by Waters (cleaned up in response to discussion)
Problem Description:
Currently, there is no portable way to inquire about the line width of
an output stream, the current position on a line, or the amount of
space that the display of a string will take up. This makes it
essentially impossible to write a portable implementation of a pretty
printer.
Proposal (STREAM-INFO: ONE-DIMENSIONAL-FUNCTIONS):
Introduce four new functions.
These functions are carefully designed with an eye to the way they
interact. As a result, they can only be defined fully in terms of
each other. The presentation below first gives a very brief
definition of each function and then gives detailed specifications of
their relationships.
LINE-WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a non-negative integer representing the line width available
when printing to OUTPUT-STREAM. If the stream has no meaningful
width (or the width cannot be computed) then NIL is returned.
LINE-POSITION &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a non-negative integer representing the current horizontal
position on the current output line, or NIL if the position cannot
be computed.
WRITE-SPACE WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [function]
Inserts blank space of length WIDTH into OUTPUT-STREAM. WIDTH must
be a non-negative integer. WRITE-SPACE returns T if the operation
is successful and NIL otherwise (e.g., if the operation is not
supported by OUTPUT-STREAM).
PRINTED-WIDTH STRING &optional (OUTPUT-STREAM *STANDARD-OUTPUT*)
&key (START 0) (END NIL) [Function]
Returns an integer representing the horizontal width that would be
required to display STRING if it were written at the current moment
to OUTPUT-STREAM using (WRITE-STRING STRING OUTPUT-STREAM :start
START :end END), or NIL if this width cannot be computed. The width
may be negative (e.g., if STRING contains backspace or newline
characters.)
PRINTED-WIDTH does not return any indication of the vertical
distance required when printing STRING. The START and END
parameters delimit a substring of STRING in the usual manner.
PRINTED-WIDTH never causes any change in the state of OUTPUT-STREAM.
The width returned may well depend on the current state of
OUTPUT-STREAM (e.g., the width of tabs depends on the line position
and the width of characters depends on the font in use.) In all
respects the width is computed based on the current state of the
stream. However, the width returned always assumes that the total
line width is infinite---i.e., does not reflect any wraparound or
truncation which might occur.
-The difficulties of a full specification:
The functions above are intended to solve a specific current problem
in CL. To serve this purpose, they must have reasonably precise
specifications. However, there are several things which make it
desirable to have specifications which allow for significant
variability between implementations. First, current implementations
of CL differ greatly in the way IO is supported, and overly strict
specifications might make things very difficult for certain
implementations. Second, CL places no limits on the kinds of
idiosyncratic characters which can be supported by particular
implementations. Third, while many CL implementations only support
the printing of characters in fixed width fonts, it is desirable to
allow for output streams that support variable width fonts.
Finally, it is desirable to leave room to move for the future.
-Operations on standard characters where the line-width has not yet been exceeded.
To deal with the problems above, a layered specification is
provided. The lowest level specification is given in terms of
constraints between the four functions above. In this lowest level
specification, two key simplifying assumptions are made. First, it
is assumed that at the time the constraint applies, none of the
previous operations on the stream S in question have caused output
to go beyond the physical horizontal limits of the output device on
the output lines relevant to the constraints. I.e., it is assumed
that truncation and or wraparound of the output has not occurred on
these lines. Second, it is assumed that all of the characters
output to the stream on the output lines relevant to the constraints
are standard characters as defined in CLTL pp 20-21. The
non-standard character #\newline may have been used to end one line
and start the next. (Note that standard characters are all simple
characters such as A-Z. Particularly, #\tab, #\backspace,
#\newline, are NOT standard characters.) It is further assumed that
the strings (X and Y) referred to in the constraints consist solely
of standard characters.
Basic properties of LINE-POSITION:
1- For all S, (not (minusp (line-position S)).
2- For all S, (zerop (line-position (progn (terpri S) S))).
3- For all S, If something is at line position N on one line and
something else is at line position N on another line, then the
two things are lined up vertically one under the other.
Defining property of WRITE-SPACE
4- For all N,S, let M = (+ (line-position S) N)
if M <= (line-width S), then
(= (line-position (progn (write-space N S) S)) M)
Defining property of PRINTED-WIDTH
5- For all X,S, let M = (+ (line-position S) (printed-width X))
if 0 <= M <= (line-width S), then
(= (line-position (progn (write-string X S) S)) M)
Basic property of LINE-WIDTH
6- For all N,S, let P = (line-position S)
If (+ P N) <= (line-width S) then
(write-space N S) is guaranteed to output space on the end of
the current line without any truncation of wraparound occurring.
7- For all X,S, let P = (line-position S)
If 0 <= (+ P (printed-width X)) <= (line-width S) then
(write-string X S) is guaranteed to output X on the end of
the current line without any truncation of wraparound occurring.
Additional properties of PRINTED-WIDTH
8- For all X,Y (= (printed-width (concatenate 'string X Y) S)
(+ (printed-width X S) (printed-width Y S)))
9- For all X,Z (= (printed-width X S)
(progn (write-string Z S) (printed-width X S)))
-Support for varying width fonts.
A key motivation behind the functions above is dealing with
arbitrary kinds of output devices and output streams that support
variable width fonts. To provide for this, the properties above
place no absolute constraints on the units used for the width
values. In fact, the units can vary from stream to stream. The
only thing that is required is that for a given stream, the units
must be a constant throughout the life of the stream, and the four
functions above must all operate in terms of the same units. The
units should be chosen to be small enough to represent the minimum
possible difference in the length of two strings and large enough
that it is possible to perform (write-space 1). (I.e., a single
pixel is a logical choice.)
If an output stream only supports a single fixed width font, then
the logical width unit to choose is the width of a single character.
Given this choice, the following is a minimal implementation of the
four functions that meets the requirements above.
LINE-WIDTH returns the maximum number of characters which can be
printed on a single line. LINE-POSITION returns the number of
characters output since the last #\newline (or since the creation of
the stream if no #\newlines have been output). (WRITE-SPACE N S)
outputs N #\space characters. Finally, (PRINTED-LENGTH X S) =
(length X).
-Support for non-standard characters and situations where line width
has been exceeded.
In the main, the properties above can be supported even if the line
width has been exceeded and even when non-standard charactres are
involved. However, characters such as #\tab and #\newline can make
it impossible to support properties 7 and 8. In addition, when the
line width is exceeded, property 3 may not hold. It is hoped that
implementors will make a good faith effort to support the functions
in the full range of situations which can be encountered in their CL
implementations. However, the simple implementation suggested above
will probably provide at least 80% of the benefits intended. As a
result, it is important that people not allow the potential
difficulties of a full implementation deter them from making a
minimal implementation.
-Support for derivative streams.
Intentionally, very little is said about what the width units should
be or exactly what LINE-WIDTH should return. The only key criterion
is that LINE-WIDTH should return a result that is pessimistic enough
to ensure proper printing. However, it is useful to make some
comments about these matters with regard to certain types of
derivative streams.
If a synonym stream, two way stream, or echo stream is created, it should
have the same line-width and width unit as the base output stream.
A string output stream should have a line-width of NIL and probably
should be treated as supporting a fixed width font and having an
output width unit so that each character has a printed-width of 1.
If a broadcast stream is created, then LINE-LENGTH, LINE-POSITION,
and PRINTED-WIDTH should be be supported by reflecting them through
to the FIRST base stream. (There is no guarantee that anything
reasonable can be done with the streams as a set. For example, one
might support a varying length font while the others don't.) An
attempt should be made to send WRITE-SPACE requests to all of the
base streams. However, they may not come out right on other than
the first base stream.
Test Case:
Suppose that S is an output stream that supports a single fixed
width font which can display 72 characters on a line and that the
associated width unit is the width of one character. Evaluating the
following will produce the results shown.
(line-width S) => 72
(terpri S) => nil
(output-position S) => 0
(printed-width "testing: " S) => 9
(write-string "testing: " S) => "testing: "
(line-position S) => 9
(write-string "foo" S) => "foo"
(terpri S) => nil
(write-space 9 S) => T
(write-string "bar" S) => "bar"
The output produced is
testing: foo
bar
Rationale:
Pretty printing requires the function LINE-WIDTH to know how wide the
output it produces can be. Pretty printing requires LINE-POSITION to
determine where on the line output is when pretty printing starts.
Pretty printing requires PRINTED-WIDTH to determine how much space
things will take in the output. (If a variable width font is being
used, this cannot be determined without a detailed knowledge of the
font being used.) (Properties 7 & 8 greatly reduce the number of
times PRINTED-WIDTH has to be called.) Pretty printing requires
WRITE-SPACE to get proper indentations. (If a variable width font is
being used, indentations may be required that cannot be obtained by
outputting spaces.)
Current Practice:
Essentially every implementation of Common Lisp must support the
minimal functionality above internally in order to support PPRINT and
the FORMAT directives ~T and ~<...~>. However, there is no documented
interface to this functionality in CLTL. As a result, while some
implementations of Common Lisp make this functionality available to
users, some do not. Further, the implementations that do provide
this functionality do so in a variety of incompatible ways.
Cost to Implementors:
This proposal is written in such a way as to allow implementations
which do not have the ability to compute difficult values to just
return NIL. Very little work is forced. The idea is to offer
implementors a common way to provide this useful information to
portable programs where possible.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Complex output programs such as pretty printers cannot be written portably.
Benefits:
A wide range of programs can gain better control of the format of output.
Aesthetics:
No significant aesthetic impact other than a slight increase in the
number of functions defined.
Discussion:
Dick Waters submitted a request for changes along the line of the
horizontal aspects of these functions in a letter to X3J13 dated
June 14, 1988. Pitman and Waters wrote up the request formally.
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is the minimum which is
required to support pretty printing into a stream which
displays output using a variable width font.
We drafted an alternate proposal, STREAM-INFO:TWO-DIMENSIONAL-FUNCTIONS,
which goes significantly beyond what is needed merely for pretty printing
and provides primitives LINE-DIMENSIONS, LINE-POSITION,
PRINTED-DIMENSIONS, and WRITE-SPACE but it is not included here.
A key point of contention which would be likely to swamp the 2d proposal
is the age old question of how to handle the issue of vertical distance
(where is the origin, which way do you count, ...). If anyone would
prefer to see larger problem 2d proposal, it could be circulated, but at
the last minute Pitman got worried that even the 1d version was going to
be controversial enough and decided to keep things focused on that.
For his own needs, Waters is strongly interested in having either
ONE-DIMENSIONAL-FUNCTIONS or TWO-DIMENSIONAL-FUNCTIONS proposal accepted,
but does not care which. Pitman concurs.
One variation of the 1d proposal might be useful to consider:
PRINTED-WIDTH could return two additional values: the number of newlines
that WRITE-STRING of the string would execute and the maximum X position
encountered (which might differ from the first value if the number of
newlines was non-zero).
This feature wasn't necessary for Waters' minimalist proposal, but Pitman
would be willing to write it in here if people thought it would be useful
enough for other purposes.
The 5th version was changed from the 4th by responding to suggestions
about better names for the functions, including a discussion of how
line-width should apply to various kinds of derivative streams, and
most importantly, by including a much more precise specification for
what the minimal capabilities of the functions should be.
----- End Forwarded Messages -----
∂08-Oct-88 2216 X3J13-mailer DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Oct 88 22:16:04 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473488; Sun 9-Oct-88 01:14:46 EDT
Date: Sun, 9 Oct 88 01:14 EDT
From: CL-Cleanup@SAIL.Stanford.EDU
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
To: X3J13@SAIL.Stanford.EDU
cc: cutting.pa@Xerox.COM
References: <880801-102621-1527@Xerox>
Message-ID: <881009011429.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
This is a DRAFT still under discussion. The "Additional Comments"
at the end are still to be dealt with.
-----
Issue: UNREAD-CHAR-AFTER-PEEK-CHAR
References: pp 379, 380 of CLtL
Category: CLARIFICATION
Edit history: Version 1 by Doug Cutting <Cutting.PA@Xerox.COM> on July 29, 1988
Problem description:
PEEK-CHAR and UNREAD-CHAR are very similar mechanisms. The description of
PEEK-CHAR in CLtL even states that "it is as if one had called READ-CHAR and
then UNREAD-CHAR in succession." But while CLtL prohibits calling UNREAD-CHAR
twice in succession it does not prohibit calling UNREAD-CHAR after PEEK-CHAR.
The obvious implementation of PEEK-CHAR and UNREAD-CHAR (a one-character buffer)
will not work unless this prohibition is present.
Proposal (UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW): UNREAD-CHAR may not be called
after PEEK-CHAR without an intervening call to READ-CHAR.
Test Cases/Examples:
;;; Following is an example of code which should not be valid CL.
(defun test (stream)
(let ((char (read-char stream)))
(peek-char nil stream)
(unread-char char stream)
(assert (eql char (read-char stream)))))
Rationale:
PEEK-CHAR and UNREAD-CHAR provide equivalent functionality and it is thus
reasonable for an implementation to implement them in terms of the same
mechanism.
Current practice:
In Xerox Common Lisp, different (non-random-access) stream types behave
differently. One, (TCP/FTP) handled this correctly, while another (keyboard with
line-buffering turned off) did not.
Cost to Implementors:
Zero. Implementations which allow this are still correct.
Cost to Users:
Small. I suspect there is very little code which depends upon this working
correctly, as most code uses either PEEK-CHAR or UNREAD-CHAR, but not both.
Cost of non-adoption:
Implementations of sequential streams are forced to be unnecessarily complex in
order to be correct.
Benefits:
Allows simple yet adequately powerful implementation of sequential streams.
Esthetics:
Requires that users have shared, one-char buffer model of how UNREAD-CHAR and
PEEK-CHAR work, rather than two separate one-char buffers.
Discussion:
- - - - - - - - - - Additional Comments - - - - - - - - - -
- The proposal part is confusingly worded.
The wording says that in a stream "abc", if I READ-CHAR to get the #\a
into variable CH1 and then I PEEK-CHAR to see the "b", then I must call
READ-CHAR before I can (UNREAD-CHAR CH1). But if I take that literally,
I'll do (SETQ CH2 (READ-CHAR S)) (UNREAD-CHAR CH1 S) and that's not what
I want. Having done the READ-CHAR, I can only UNREAD-CHAR the char I just
did READ-CHAR to get. In effect, I can never UNREAD-CHAR CH1 once I've
peeked at or read the next char. Some streams will let me back up at this
point, but only those which would have let me back up before doing the
READ-CHAR in the first place.
It would be clearer for the proposal to just say that doing either a
PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
on any character preceding that which is seen by the PEEK-CHAR (including
those passed over by PEEK-CHAR when `seeking' with a non-NIL first
argument) is not portable.
- A misreading of the proposal might lead one to believe that one could
do (SETQ CH1 (READ-CHAR STREAM))
(SETQ CH2 (PEEK-CHAR NIL STREAM))
(SETQ CH3 (READ-CHAR STREAM))
(UNREAD-CHAR CH1 STREAM)
since the unread-char is correctly separated from the PEEK-CHAR by an
intervening READ-CHAR. The problem is that the wrong char is being
unread. Some implementations support this, but it's definitely not
condoned by the description of UNREAD-CHAR on p379.
- I found the following test case to be more insightful:
(defun test (&optional (stream *standard-input*))
(let* ((char1a (read-char stream))
(char2a (peek-char nil stream))
(char1b (progn (unread-char char1a stream)
(read-char stream)))
(char2b (read-char stream)))
(list char1a char2a char1b char2b)))
- Current practice (for my test case above) in Symbolics Genera:
(test)ab
=> (#\a #\b #\a #\b)
(with-input-from-string (s "abc") (test s))
=> (#\a #\b #\a #\b)
(progn (with-open-file (s "foo.output" :direction :output)
(write-string "abc" s))
(with-open-file (s "foo.output" :direction :input)
(test s)))
Signals an error about unreading #\a when #\b was already unread.
∂09-Oct-88 0230 X3J13-mailer Draft Issue: CLOS-CONDITIONS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Oct 88 02:30:05 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473546; Sun 9-Oct-88 05:28:47 EDT
Date: Sun, 9 Oct 88 05:28 EDT
From: CL-ERROR-HANDLING@SAIL.Stanford.EDU
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Draft Issue: CLOS-CONDITIONS (Version 3)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <881009052832.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
There's been some disagreement about a couple of details, so this may
change yet again before we ask you to vote on it, but this is the
version that is likely to be presented for comment at the meeting.
The conflict is represented in the writeup by the presence of two
variant proposals, YES-OPTION-A and YES-OPTION-B.
-----
Issue: CLOS-CONDITIONS
References: Condition System (Revision 18)
Category: ADDITION
Edit history: 26-Sep-88, Version 1 by Pitman
06-Oct-88, Version 2 by Pitman
09-Oct-88, Version 3 by Pitman
Status: For Internal Discussion
Problem Description:
The description of the Common Lisp condition system presupposes
only DEFSTRUCT and not DEFCLASS because it was written when
CLOS had not been adopted. It is stylistically out of step with
CLOS in a few places and places some restrictions which are not
necessary if CLOS can be presupposed.
Subproposal (CLOS-CONDITIONS:YES):
[These options are very similar. They agree except as otherwise noted.]
Define that condition types are CLOS classes.
Define that condition objects are CLOS instances.
Permit multiple parent-types to be named in the list of
parent types. Define that these parent types are treated the
same as the superior class list in a CLOS DEFCLASS expression.
Define that slots in condition objects are normal CLOS slots.
Note that WITH-SLOTS can be used to provide more convenient
access to the slots where slot accessors are undesirable.
Functions such as SIGNAL, which take arguments of class names,
are permitted to take class objects. Such class objects must
still be subclasses of CONDITION.
Eliminate the :CONC-NAME option to DEFINE-CONDITION.
Define that condition reporting is mediated through the
PRINT-OBJECT method for the condition type (class) in question,
with *PRINT-ESCAPE* always being NIL. Specifying
(:REPORT fn) in the definition of a condition type C is
equivalent to doing
(DEFMETHOD PRINT-OBJECT ((X c) STREAM)
(IF *PRINT-ESCAPE* (CALL-NEXT-METHOD) (fn X STREAM)))
Proposal (CLOS-CONDITIONS:YES-OPTION-A):
All of subproposal YES, plus the following...
Extend the syntax for a slot in a DEFINE-CONDITION as follows...
- If a symbol is used, DEFINE-CONDITION will by special case
treat this as if (symbol :INITARG keyword :READER reader-name)
were specified instead, where KEYWORD is generated by
(INTERN (SYMBOL-NAME symbol) (FIND-PACKAGE "KEYWORD"))
and reader-name is generated by
(INTERN (FORMAT NIL "~A-~A" condition-type symbol))
for CONDITION-TYPE being the condition type being defined.
- A length 1 list, (symbol), is treated the same as providing
the symbol itself.
- If a length 2 list, (symbol value) is provided, it is treated
as (symbol :INITARG keyword :READER reader-name :INITFORM value),
with KEYWORD and READER-NAME being computed as above.
- If a list of length greater than 2 is used, it is treated
the same as a CLOS slot-specifier. In that case, the :INITARG
and :READER options must be explicitly specified if desired.
This syntax is compatible with the existing semantics of
DEFINE-CONDITION.
Rationale:
This provides maximal compatibilty with the old semantics
for DEFINE-CONDITION, which numerous vendors now distribute.
Further, and perhaps more importantly, the uses of slots in
DEFINE-CONDITION are highly constrained. They are not assigned
so an INITARG is nearly always needed. There are almost
universally accessed externally, so a :READER is usually
needed. This syntax makes what is by far the most convenient
use very syntactically simple.
Proposal (CLOS-CONDITIONS:YES-OPTION-B):
Incompatibly change the syntax of a slot in DEFINE-CONDITION
to be compatible with a DEFCLASS slot specification.
An implication of this change is that forms like
(DEFINE-CONDITION FOO (BAR) ((A 1) (B 2)))
would have to be written
(DEFINE-CONDITION FOO (BAR) ((A :INITARG :A :READER FOO-A :INITFORM 1)
(B :INITARG :B :READER FOO-B :INITFORM 2)))
Rationale: This is most compatible with CLOS.
Examples:
Slot specifiers...
Under YES-OPTION-A ...
A slot specifier of X in condition type FOO is still valid
and means the same as (X :INITARG :X :READER FOO-X).
A slot specifier of (X) in condition type FOO is still valid
and means the same as (X :INITARG :X :READER FOO-X).
A slot specifier of (X V) in condition type FOO is still
valid and means the same as
(X :INITARG :X :READER FOO-X :INITFORM V).
In addition, other slot specifiers such as
(X :INITARG :EX :TYPE FIXNUM)
are permitted as in DEFCLASS.
Under YES-OPTION-B ...
A slot specifier of X is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X) is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X V) would no longer be valid.
In addition, other slot specifiers such as
(X :INITARG :EX :TYPE FIXNUM)
are permitted as in DEFCLASS.
Conc names ...
(DEFINE-CONDITION FOOBAR (FOO BAR) (X Y) (:CONC-NAME FUBAR))
would be rewritten
(DEFINE-CONDITION FOOBAR (FOO BAR)
((X :INITARG :X :READER FUBAR-X)
(Y :INITARG :Y :READER FUBAR-Y)))
Report methods ...
(DEFINE-CONDITION OOPS (ERROR) ())
(DEFMETHOD PRINT-OBJECT ((X OOPS) STREAM)
(IF *PRINT-ESCAPE*
(CALL-NEXT-METHOD)
(FORMAT STREAM "Oops! Something went wrong.")))
(ERROR 'OOPS)
>>Error: Oops! Something went wrong.
Rationale:
These changes are consistent with the intent of the recent
X3J13 endorsement of CLOS and the Common Lisp Condition System.
The shorthand notations for DEFINE-CONDITION's slots spec
are justified since the the way in which condition slots are
used is much more highly constrained than for arbitrary classes.
This means we can predict what will be the common case and make
it far more syntactically convenient than it might otherwise be.
Although flushing :CONC-NAME is an incompatible change, nothing
forbids an implementation from supporting it as an extension
during a transition period.
Current Practice:
Some implementations supporting CLOS probably already do this,
or something very similar.
Cost to Implementors:
If you really have CLOS, this is very straightforward.
Cost to Users:
Small, but tractable.
The main potential problems are:
- :CONC-NAME. There is nothing that keeps an implementation from
continuing to support :CONC-NAME for a short while until old code
has been upgraded.
- The incompatible change to slot syntax. Again, it is possible to
unambiguously recognize a 2-list as old-style syntax and an
implementation can provide interim compatibility support during
a transition period.
Even if implementations did not provide the recommended compatibility
support, users could trivially shadow DEFINE-CONDITION and provide the
support themselves, expanding into the native DEFINE-CONDITION in the
proper syntax.
Cost of Non-Adoption:
Conditions will seem harder to manipulate than other user-defined types.
People will wonder if CLOS is really something we're committed to.
Benefits:
A more regular language.
Aesthetics:
Anything that makes the language more regular improves the aesthetics.
Discussion:
People seem to disagree about the status that CLOS might occupy
in the upcoming standard. In spite of a vote of support, they seem
to think it might be optional in some way. Passing this proposal
establishes a clear precedent for the full integration of CLOS into
the emerging language.
Moon suggests that we might want to add condition types for the errors
CLOS might signal. It isn't obvious (to Pitman, at least) that this
change is as straightforward as it looks, though, so it will have to
come up under separate cover.
Richard Mlynarik suggests adding a generic function, REPORT-CONDITION,
which is used for reporting conditions. It is possible to discuss such
a generic function as a separate issue layered atop the substrate which
this proposal provides, so that issue has been deferred.
Pitman supports this change, with mild preference for YES-OPTION-A.
Gregor supports this change, with strong preference for YES-OPTION-B.
∂14-Oct-88 1427 X3J13-mailer Issue: RANGE-OF-COUNT-KEYWORD (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Oct 88 14:26:15 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476697; Fri 14-Oct-88 17:26:16 EDT
Date: Fri, 14 Oct 88 17:26 EDT
From: CL-Cleanup@SAIL.Stanford.EDU
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: RANGE-OF-COUNT-KEYWORD (Version 3)
To: X3J13@SAIL.Stanford.EDU
Supersedes: <881009001850.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-ID: <881014172603.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: RANGE-OF-COUNT-KEYWORD
References: :COUNT (p247), REMOVE[-xxx] (p253), DELETE[-xxx] (p254),
[N]SUBSTITUTE[-xxx] (pp255-256)
Category: CLARIFICATION
Edit history: 21-Aug-88, Version 1 by Dave Touretzky
22-Aug-88, Version 2 by Pitman
09-Oct-88, Version 3 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL is overly vague about legal values for the :COUNT keyword
parameters to builtin functions such as the sequence functions. It
says that the keyword ``limits the number of elements [affected]''.
Implementations have varied in their interpretation of this phrase,
however.
CLtL p247 specifies that if the :COUNT parameter to functions such
as REMOVE and DELETE ``is NIL or is not supplied, all matching items
are affected.'' Because of the placement of this requirement
outside of the description of the functions affected, some
implementations have overlooked this requirement and had to be
changed later.
CLtL doesn't say explicitly that the value of :COUNT must be an
integer, nor does it say what to do for negative values.
The fact that reasonable implementations disagree on some of the
details make this an obvious candidate for cleanup.
Proposal (RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER):
Clarify that for the functions
REMOVE REMOVE-IF REMOVE-IF-NOT
DELETE DELETE-IF DELETE-IF-NOT
SUBSTITUTE SUBSTITUTE-IF SUBSTITUTE-IF-NOT
NSUBSTITUTE NSUBSTITUTE-IF NSUBSTITUTE-IF-NOT
the following restrictions on the :COUNT keyword parameter exist:
* The value of this parameter must be NIL or an integer.
* Using a negative integer value is functionally equivalent to
using a value of zero.
Test Case:
#1: (REMOVE 'A '(A B A B) :COUNT 0) => (A B A B)
#2: (REMOVE 'A '(A B A B) :COUNT -3) => (A B A B)
#3: (REMOVE 'A '(A B A B) :COUNT NIL) => (B B)
#4: (REMOVE 'A '(A B A B) :COUNT 1.0) is an error.
#5: (REMOVE 'A '(A B A B) :COUNT 'FOO) is an error.
Rationale:
Disallowing non-integer numbers is probably the original intent and
is consistent with other functions such as NTH (p265) which accept
count-like arguments that are explicitly required to integers. This
restriction would presumably permit better optimizations in low-safety
mode on stock hardware.
Allowing NIL to be equivalent to no value allows a simplified flow
of control in some situations. For example, one can write
(DEFUN MYDEL (ITEM &OPTIONAL COUNT)
(DELETE ITEM *MYLIST* :COUNT COUNT))
where otherwise it might be necessary to write something like
(DEFUN MYDEL (ITEM &OPTIONAL (COUNT NIL COUNT-P))
(IF COUNT-P
(DELETE ITEM *MYLIST* :COUNT COUNT)
(DELETE ITEM *MYLIST*)))
Allowing negative numbers frees users from having to do an explicit
check for negative numbers when the value of :COUNT is computed by
some complicated expression. For example:
(DEFUN LEAVE-AT-MOST (N ITEM SEQUENCE &KEY (FROM-END T))
(REMOVE ITEM SEQUENCE
:COUNT (PRINT (- (COUNT ITEM SEQUENCE) N))
:FROM-END FROM-END))
(LEAVE-AT-MOST 2 #\A "BANANAS") ==> "BANANS"
(LEAVE-AT-MOST 2 #\S "BANANAS") ==> "BANANAS"
Current Practice:
[Note: Pitman didn't try these examples in KCL or CMU Common Lisp. He's
working from data in Touretzky's last draft of this proposal, so someone
from those camps might want to test the assertions made here.]
#1: All correct implementations presumably return (A B A B).
This value is consisent with this proposal.
#2: Symbolics Cloe returns (A B A B).
KCL returns (A B A B) for lists.
This value is forced by this proposal.
Symbolics Genera and CMU Common Lisp return (B B).
KCL does something bizarre for vectors (``pads with n blanks or
NILs, where -n is the value of the :count keyword parameter'',
says Touretzky.)
These implementations would have to change.
#3: All correct implementations presumably return (B B).
This value is consisent with this proposal.
Some implementations have been known to signal a wrong type
argument error in the past, but have presumably been fixed.
#4: Symbolics Genera and Symbolics Cloe return (B A B).
CMU Common Lisp returns (B B).
These behaviors are consistent with this proposal.
#5: Symbolics Cloe and Symbolics Genera signal an error.
CMU Common Lisp returns (A B A B).
These behaviors are consistent with this proposal.
Cost to Implementors:
Some implementations would have to change. These functions are typically
heavily optimized by compilers. Not only source code, but also compiler
optimizers and perhaps even microcode or hardware might have to be
modified to fully accomodate this change, so it might be quite expensive.
Cost to Users:
None for Common Lisp users. This change is an upward compatible
clarification of standard practice.
Cost of Non-Adoption:
The behavior of these functions when given degenerate keyword values would
be unintuitive. In many such cases, considerable additional user code must
be written to watch for and avoid creating such situations.
Benefits:
More compact, more intuitive, and more portable code.
Aesthetics:
This change improves language aesthetics.
Discussion:
In the past there has been some argument about what SUBSEQ should do when
given positions greater than the length of the sequence. Currently it
"is an error" to specify positions less than zero or greater than the
length of the sequence. Touretzky doesn't think the same should apply to
the :COUNT keyword. The inputs to SUBSEQ are ordinal numbers: they specify
positions, like array subscripts. The value of :COUNT is not an ordinal,
it is an upper bound on the size of the set of affected items (which is
a cardinal number).
Pitman supports this proposal. [Hopefully Touretzky supports it, too?]
van Roggen says he personally supports the stated proposal but that a
survey he did of users at DEC showed up a number of people who thought
that negative count arguments should be an error.
∂18-Oct-88 2146 CL-Cleanup-mailer DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Oct 88 21:46:16 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA06569g; Tue, 18 Oct 88 21:46:10 PDT
Received: by bhopal id AA03592g; Tue, 18 Oct 88 21:44:37 PDT
Date: Tue, 18 Oct 88 21:44:37 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810190444.AA03592@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 8 Oct 88 22:07 PDT <881008-220711-2583@Xerox>
Subject: DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
Several others have already expressed my sentiments towards this proposal --
that it would have been a nice idea five years ago, but is a gratuitous
incompatibility now. "Gratuitous", because lots of uses will have to
worry about whether or not their code needs to be massaged, and the
_payback_ to them will be insignificant.
It would certainly be acceptable to "deprecate" the use of any ...-IF-NOT
function, and of the :TEST-NOT keyword argument; this ought to be an
editorial discretion, rather than requireing lots of cl-cleanup time.
-- JonL --
∂25-Oct-88 0852 X3J13-mailer Proposed US Position Statement
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The following is my proposed US position statement for ISO:
*********************************************************************
The US is currently supporting two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Therefore, the US sees no need at this time
to standardize another dialect of Lisp for use within the US. It
follows that the primary activity of WG16 is not of major importance
within the US.
Nevertheless, it appears that WG16 is planning to provide a useful
standard for Europe. For this reason, WG16 is currently defining a
dialect of Lisp called ``ISLISP'' suitable for the needs of the European
community. The US is happy to aid that process.
Common Lisp and Scheme are beginning to enjoy widespread use not only
in the US but internationally. The charter for WG16 that was
determined at its first meeting in February 1988 allows for
standardization of multiple dialects of Lisp. Therefore, the US wishes
for WG16 to propose to ISO a standard for ISO Common Lisp, to be
called ``ISO Common Lisp.'' As ISLISP is aimed at satisfying certain
needs for a certain community, so ISO Common Lisp would be aimed at
satisfying the Common Lisp needs for a certain community. The US
wishes to reserve the right to request that WG16 propose to ISO a
standard for ISO Scheme.
By making this request, the US does not intend to impede or negate the
work of WG16 on ISLISP, just as we presume that the work of the
committee on ISLISP is not intended to impede or negate the work of
X3J13 on Common Lisp or of IEEE on Scheme in the US.
The community of Common Lisp users and implementors is international
in nature: Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). ANSI is not an
international standards organization, and so it is appropriate for
WG16 to propose a standard for ISO Common Lisp to ISO. Furthermore, it
is common for various US funding agencies to require projects to be
undertaken in ISO languages when they are available. Just as it would
be unfair for Common Lisp to be imposed by law in contexts where it is
not wanted, so it would be unfair for ISLISP to be imposed within the
US. For this reason, it is important for ISO to adopt Common Lisp as
an ISO standard language.
Common Lisp has been under design and specification for 8 years.
Commercial versions of Common Lisp have been available for 4 years. It
has been shown that small memory Common Lisp implementations are
possible and that small applications can be delivered. The key is in
implementation technology and not in language design. There are a
number of companies whose entire revenue depends on selling software
written in Common Lisp. The Defense Advanced Research Projects Agency
allows software to be written in Common Lisp (as well as Ada).
The US feels that the most interesting task for WG16 is towards a next
generation dialect of Lisp, combining the best aspects of Common Lisp,
Scheme, the Common Lisp Object System (now officially part of Common
Lisp), and other interesting (possibly parallel) dialects of Lisp.
The US believes that this task can begin once the needs of current
Lisp programmers and implementors is satisfied with ISO ISLISP and ISO
Common Lisp.
∂25-Oct-88 1405 X3J13-mailer Comments on Cleanup issues due within two weeks
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 Oct 88 14:05:19 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 25 OCT 88 13:50:39 PDT
Date: 25 Oct 88 13:50 PDT
From: masinter.pa@Xerox.COM
Subject: Comments on Cleanup issues due within two weeks
To: X3J13@Sail.stanford.edu
reply-to: CL-Cleanup@sail.stanford.edu
Message-ID: <881025-135039-11718@Xerox>
As was discussed in the October X3J13 meeting, there will be a letter
ballot on the outstanding previously distributed cleanup issues. In order
for us to respond to your comments, we need to receive any comments on any
of the issues that were mailed electronically and distributed in hardcopy
within the next two weeks. If you feel that the cleanup proposals as
written adequately consider all of the possible alternatives, properly
address the costs and benefits of the proposal, we don't need to hear from
you. However, if there are considerations you believe are not reflected in
the writeup, please speak up. So far, we have heard from very few people.
I expect at the January meeting that there will be discussion of those
issues that we were unable to prepare for the October meeting, and there
will be some opportunity to discuss the items and the results of the letter
ballot, but I hope you will take the time, now, to consider the issues
already distributed.
You will do those of us who try to track cleanup mail a favor if you will
use a separate message for each Issue, with Subject: Issue: ISSUE-NAME
(Version number), addressed To: CL-Cleanup@sail.stanford.edu. Will will try
to ensure that all contributors are cc'd in subsequent discussion.
Thanks,
Larry Masinter
∂26-Oct-88 1925 X3J13-mailer Proposed US Position Statement
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88 19:25:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482712; Wed 26-Oct-88 22:25:20 EDT
Date: Wed, 26 Oct 88 22:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposed US Position Statement
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: x3j13@SAIL.Stanford.EDU
In-Reply-To: <$7Wc0@SAIL.Stanford.EDU>
Message-ID: <19881027022508.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is fine with me, except for the part at the end suggesting that
the best place to do Lisp language research is in an ISO standards
committee. That seems like the worst place to me.
∂28-Oct-88 0347 X3J13-mailer mailing list update
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 28 Oct 88 03:47:26 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA22930; Fri, 28 Oct 88 03:47:05 PDT
Message-Id: <8810281047.AA22930@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 28 Oct 88 06:44
To: x3j13@sail.stanford.edu
Subject: mailing list update
Please remove Ron Ohlander from x3j13.
∂01-Nov-88 1237 X3J13-mailer March meeting
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 88 12:35:25 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00995g; Tue, 1 Nov 88 12:34:40 PST
Received: by challenger id AA01605g; Tue, 1 Nov 88 12:30:50 PST
Date: Tue, 1 Nov 88 12:30:50 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8811012030.AA01605@challenger>
To: x3j13@sail.stanford.edu
Subject: March meeting
Bob Mathis will be hosting the March X3J13 and ISO meetings in the new Contel
facilities. Thank you Bob!
Please mark your calendars.
3/27 - 3/29 X3J13, Washington, D.C. area
3/30 - 3/31 ISO, Washington, D.C. area
---jan---
∂01-Nov-88 1245 X3J13-mailer March meeting
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 1 Nov 88 12:45:25 PST
Return-Path: <hadden@src.honeywell.com>
Received: from ella.SRC.Honeywell.COM
by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88)
id AA21106; Tue, 1 Nov 88 14:45:20 CST
Posted-Date: Tue, 1 Nov 88 14:43:47 CST
Received: by ella.src.honeywell.com (3.2/SMI-3.2)
id AA22306; Tue, 1 Nov 88 14:43:47 CST
Date: Tue, 1 Nov 88 14:43:47 CST
From: hadden@src.honeywell.com (George D. Hadden)
Message-Id: <8811012043.AA22306@ella.src.honeywell.com>
To: jlz@lucid.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Tue, 1 Nov 88 12:30:50 PST <8811012030.AA01605@challenger>
Subject: March meeting
oops, never mind about the dates.
-geo
∂02-Nov-88 0930 X3J13-mailer Hawaii hotel reservations reminder
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Nov 88 09:30:11 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00503g; Wed, 2 Nov 88 09:29:23 PST
Received: by challenger id AA03055g; Wed, 2 Nov 88 09:25:32 PST
Date: Wed, 2 Nov 88 09:25:32 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8811021725.AA03055@challenger>
To: x3j13@sail.stanford.edu
Subject: Hawaii hotel reservations reminder
Please ask for Lizann when calling the Sheraton Coconut Grove 8:00 - 5:00
Monday - Friday. She is the one who can give you the special rate of
$80/night.
808/822-3455
---jan---
∂02-Nov-88 1612 X3J13-mailer Re: Proposed US Position Statement
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Nov 88 16:12:11 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 NOV 88 16:05:27 PST
Date: Wed, 2 Nov 88 16:05 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Proposed US Position Statement
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: x3j13@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <$7Wc0@SAIL.Stanford.EDU>
Message-ID: <19881103000503.4.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
We would like to comment on your proposed US position statement for ISO
WG16. We agree with much of what you say in your statement. Critically,
we agree that the U.S. must seek a change in the current ISO direction.
But we feel that your statement does not make sufficiently clear those
responsibilities which lead the X3J13 committee to this position. X3J13
is the committee we are most familiar with. We believe that the IEEE
group working standardization of Scheme may have similar concerns, but
we do not presume to speak for them.
The X3J13 effort is quite mature. We have almost finished the standard
we are chartered to develop. Most technical decisions have been made,
and the ones that remain to be made have already received significant
discussion and study. Editorial work to produce the standards document
is already well underway.
A number of individuals and companies have devoted significant time and
resources to creating the X3J13 Common Lisp standard. An even larger
number of individuals and companies have devoted resources to preparing
themselves to use this standard. The X3J13 committee has a significant
commitment to these individuals and companies; we must finish the
language we set out to create, and must follow through on our commitment
to making it an ANSI standard.
An important part of this commitment is that we cannot at this point
take any action which would diminish the value the standard we have
worked so hard to create. This responsibility constrains our options in
working with the ISO standardization effort. These constraints can be
complex and difficult to understand. This accounts in part for the time
it has taken the U.S. delegation to develop this position statement.
But one such constraint is now clear: The X3J13 committee cannot
endorse the development of an ISO standard which is as similar to Common
Lisp as ISLisp is currently. An ISO standard which is targeted that
close to the Common Lisp language being developed by X3J13, should be
exactly the same that being developed by X3J13.
The existence of a similar but separate ISO standard would significantly
weaken the ANSI Common Lisp standard. Problems would be caused by
policies that mandate the use of ISO standards over ANSI standards;
perhaps these problems could be resolved, but it would take time. It is
precisely to avoid those kinds of problems that our "constituency" has
chartered us to develop ANSI Common Lisp.
In addition, there would be widespread confusion among educators,
authors, application vendors and others about which Common Lisp was the
standard one. The technical leaders of the X3J13 effort would be
rightly criticized for not being committed to the language they created.
The United States is, however, part of the ISO Lisp standardization
process. As part of that process we must decide how to resolve the
obligations we are under to our X3J13 constituency with the obligations
that other delegations have to their constituencies. We would like to
try and do so in the most generous and equitable way possible. At this
point, it appears that the idea of multiple ISO standards is the best
solution.
One of these ISO standards would be the language currently being
specified by the X3J13 committee. This could be called ISO Common Lisp.
We would of course actively encourage additional cleanup proposals to
ensure that the language is in fact suitable for use as an international
standard. An important part of this is the commitment to working out
the character set proposal.
Other ISO standards could be developed for other specific purposes.
Those standards would have to be sufficiently different from ISO Common
Lisp that they would not diminish that standard. It might be possible
to develop a strict subset of ISO Common Lisp, but we do not believe it
is possible do so in a short timeframe.
We understand, and we believe the entire X3J13 committee understands,
that this position may be perceived as inflexible by certain other
members of the ISO committee. We would ask those members to consider
the commitment we have to the individuals and companies which have
plans to use X3J13 Common Lisp. We simply cannot take an action which
would compromise that commitment.
Daniel G. Bobrow
Scott Fahlman
Gregor Kiczales
Larry Masinter
-------
∂07-Nov-88 0639 X3J13-mailer Re: Proposed US Position Statement
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 7 Nov 88 06:38:55 PST
Date: 7 Nov 1988 09:37-EST
Sender: ROSENKING@A.ISI.EDU
Subject: Re: Proposed US Position Statement
From: ROSENKING@A.ISI.EDU
To: Gregor.pa@XEROX.COM
Cc: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 7-Nov-88 09:37:07.ROSENKING>
In-Reply-To: <19881103000503.4.GREGOR@PORTNOY.parc.xerox.com>
I wish to extend my support to the comments made by Bobrow et al, in
reference to Dick Gabriel's Proposed US Position Statement. I have
volunteered my time, effort and company's support to assist in
developing a Common Lisp standard. Each individuals participation in
X3J13 constitutes a major investment in Common Lisp. I agree that we
should protect our investment and thereby support this proposal.
Jeff Rosenking
∂07-Nov-88 1517 X3J13-mailer US Position Statement (Version 2)
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I'd like to thank the following people for providing helpful comments
about my proposed US Position Statement:
Danny Bobrow, Kathy Chapman, Will Clinger, Linda DeMichiel, Patrick
Dussud, Scott Fahlman, Chris Haynes, Jim Kempf, Gregor Kiczales, Thom
Linden, Larry Masinter, Dave Moon, Kent Pitman, Guy Steele, and JonL
White.
As I've mentioned before, I am your representative, and my job is to
represent your position at the ISO meetings. The following the is current
(and I presume the final) position statement:
**************************************************************************
The US is currently undertaking two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Within the United States, there is no demand
for another Lisp standard at this time.
The current activity of WG16 is to develop a standard for a dialect of
Lisp directed at a community of users who are served neither by Common
Lisp nor by Scheme---that dialect is IsLisp. Although IsLisp will not
be of major importance within the US, the US supports the IsLisp
standardization effort as long as it does not negatively affect
standards for other dialects of Lisp. In particular, the US feels
that it is important not to have two standardized dialects of Lisp
that are nearly identical unless one is a strict subset of the other.
Having two such similar but different dialects weakens the position of
users who have come to depend on one of the dialects.
The US believes that the primary focus of standardization is to codify
existing practice to support the creation and delivery of portable
software. Thus, the major focus of the US standardization efforts is
to provide stability to the community of Common Lisp and Scheme users.
Of secondary importance are the invention of new Lisp dialects and the
standardization of Lisp dialects or features not in common usage. The
US therefore agrees with the ISO goal of a near term standard in the
1990 time frame along with longer range consideration of future
dialects and features.
Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). In each of these
countries there are companies whose customers depend on portable
software written in Common Lisp. The future of these companies
thus depends on having a Common Lisp standard. Furthermore, it is
common for various US funding agencies to require projects to be
undertaken in ISO languages when they are available. Just as it would
be unfair for Common Lisp to be imposed by law in contexts where it is
not wanted, so it would be unfair for IsLisp to be imposed within the
US.
For these reasons, the US proposes that WG16 produce a draft standard
for ISO Common Lisp. As IsLisp is aimed at satisfying certain needs
for a specific community, so ISO Common Lisp would be aimed at
satisfying the Common Lisp needs for the international Common Lisp
community. The US wishes to reserve the right to request that WG16
produce a draft standard for ISO Scheme.
The US believes that Common Lisp is a valid candidate for
international standardization both because it is used internationally
and also because it is a mature and stable dialect. Common Lisp has
been under design and specification for 8 years. Commercial quality
implementations of Common Lisp have been available for 4 years. It
has been shown that small memory Common Lisp implementations are
possible and that small applications can be delivered: The key to
small applications lies more in implementation technology and the
environment than in language design. The near term standardization of
ISO Common Lisp would have substantial positive impact on the
acceptance of existing commercial Lisp implementations and of all
future Lisp dialects as vehicles for emerging applications.
The US believes that WG16 is the appropriate working group to
standardize Common Lisp. As determined at its first meeting, the
charter of WG16 endorses the standardization of multiple dialects of
Lisp. Therefore, WG16 can choose to produce draft standards for both
Common Lisp and IsLisp. It is not sufficient that there be only an
ANSI standard for Common Lisp because ANSI is not an international
standards organization.
The US feels that a draft standard for ISO Common Lisp could be
prepared by December 1989 with the assistance of X3J13. The US
proposes that WG16 request X3J13 to prepare the ISO draft standard for
Common Lisp. The ISO Common Lisp draft and the ANSI Common Lisp draft
should be identical.
Looking beyond Common Lisp, IsLisp, and Scheme, the US feels that an
important task for WG16 is working towards a next generation dialect
of Lisp, and this can be accomplished by drawing on the lessons learned
from existing dialects of Lisp.
∂09-Nov-88 1137 X3J13-mailer Official US Position
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The following is the official US position statement, which was
hammered out by myself and the following people:
Danny Bobrow, Kathy Chapman, Will Clinger, Linda DeMichiel, Patrick
Dussud, Scott Fahlman, Chris Haynes, Jim Kempf, Gregor Kiczales, Thom
Linden, Larry Masinter, Dave Moon, Kent Pitman, Guy Steele, and JonL
White.
I'd like to especially thank Thom Linden and Gregor Kiczales with
whom I exchanged about 75 drafts over the last 24 hours.
*********************************************************************
The US is currently undertaking two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Within the United States, there is no demand
for another Lisp standard at this time.
The current activity of WG16 is to develop a standard for a dialect of
Lisp directed at a community of users who are served neither by Common
Lisp nor by Scheme---that dialect is IsLisp. Although is is unlikely
that IsLisp will have major near term commercial significance within
the US, the US supports the IsLisp standardization effort as long as
it does not negatively affect standards for other dialects of Lisp.
In particular, the US feels that it is important not to have two
standardized dialects of Lisp that are nearly identical unless one is
a strict subset of the other. Having two such similar but different
dialects weakens the position of users who have come to depend on one
of the dialects.
The US believes that the primary focus of standardization is to codify
existing practice to support the creation and delivery of portable
software. Thus, the major focus of the US standardization efforts is
to provide stability to the community of Common Lisp and Scheme users.
Of secondary importance are the invention of new Lisp dialects and the
standardization of Lisp dialects or features not in common usage. The
US therefore agrees with the ISO goal of a near term standard in the
1990 time frame along with longer range consideration of future
dialects and features.
Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). In each of these
countries there are companies whose customers depend on portable
software written in Common Lisp. The future of these companies thus
depends on having a Common Lisp standard.
The US believes that Common Lisp is a valid candidate for
international standardization both because it is used internationally
and also because it is a mature and stable dialect. Common Lisp has
been under design and specification for 8 years. Commercial quality
implementations of Common Lisp have been available for 4 years. It
has been shown that small memory Common Lisp implementations are
possible and that small applications can be delivered: The key to
small applications lies more in implementation technology and the
environment than in language design. The near term standardization of
ISO Common Lisp would have substantial positive impact on the
acceptance of existing commercial Lisp implementations and on the
viability of future Lisp dialects as vehicles for emerging
applications.
For these reasons, the US proposes the development of an ISO standard
for Common Lisp. Furthermore, the US proposes that WG16 request X3J13
to prepare the ISO draft standard for Common Lisp. The ISO Common
Lisp draft and the ANSI Common Lisp draft should be identical. The US
believes such a draft standard could be developed by December 1989.
The US also believes the development of an ISO standard for Common
Lisp is within the charter of WG16, which endorses the standardization
of multiple dialects of Lisp. At some point in the future, it may be
appropriate to develop an ISO standard for Scheme.
Looking beyond near term standardization, the US feels that an
important task for WG16 is working towards a next generation dialect
of Lisp, and this can be accomplished by drawing on the lessons
learned from existing dialects of Lisp.
∂14-Nov-88 0804 X3J13-mailer Re: Hawaii hotel reservations reminder
Received: from mitre.arpa by SAIL.Stanford.EDU with TCP; 14 Nov 88 08:03:52 PST
Full-Name: Jim Antonisse
Message-Id: <8811141546.AA14091@mitre.arpa>
Organization: The MITRE Corp., Washington, D.C.
To: Jan Zubkoff <jlz@lucid.com>
Cc: x3j13@sail.stanford.edu, jima@mitre.arpa
Subject: Re: Hawaii hotel reservations reminder
In-Reply-To: Your message of Wed, 02 Nov 88 09:25:32 -0800.
<8811021725.AA03055@challenger>
Date: Mon, 14 Nov 88 10:46:00 EST
From: jima@mitre.arpa
Jan,
What is the registration fee for Hawaii, and to whom should
I make out the check. (Apologies if you've sent this info out
before, I recently - rather rashly, I guess - flushed my mail
log.)
The agenda hasn't taken shape already, has it?
Jim A.
∂14-Nov-88 1130 X3J13-mailer Ignore that message
Received: from mitre.arpa by SAIL.Stanford.EDU with TCP; 14 Nov 88 11:30:41 PST
Full-Name: Jim Antonisse
Message-Id: <8811141928.AA16983@mitre.arpa>
Organization: The MITRE Corp., Washington, D.C.
To: x3j13@sail.stanford.edu
Subject: Ignore that message
Date: Mon, 14 Nov 88 14:28:40 EST
From: jima@mitre.arpa
Well, "repl" was a just a bit more zealous than I expected
it to be. Sorry to {x3j13 - Jan} for the dose of mistargeted
mail - Jim A.
∂20-Nov-88 0359 X3J13-mailer Phase 1 standard
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Nov 88 03:59:10 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA25899; Sun, 20 Nov 88 03:58:33 PST
Message-Id: <8811201158.AA25899@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Nov 88 06:49
To: x3j13@sail.stanford.edu
Subject: Phase 1 standard
The source files for the phase 1 standard (complete as far as we know now)
are located on hudson.dec.com. The account name is FTP_USER and the password
is FTPPLEASEWORK.
Please let me know your specific needs if you intend to review this document.
The .dvi files will be available by Dec. 2. If you intend to use those, the
file names are chapter1.dvi...chapter6.dvi, and chapter6-1.dvi. The chapter 6
files are quite large.
If you want to build the document from the source files, you will need
TEX and TEX amfonts on your machine. To build the document, you invoke
TEX 7 times, each time with the file name chapterx, where
x=1,2,3,4,5,6,6-1.
Please let me know if you have any problems.
kathy chapman
∂29-Nov-88 1235 X3J13-mailer ISO Meeting Report
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Fellow Colleagues:
The following is my report on the November ISO meeting. I am sending
this now for several reasons. First, because it is fresh in my mind.
Second, because the events are a little more dramatic than usual.
Third, because one outcome was the cancellation of the January ISO
meeting in Hawaii.
The US Delegation consisted of Bob Mathis, Thom Linden, Patrick
Dussud, Gregor Kiczales, and myself. The meeting was held at the
Building of the European Community in Brussels, Belgium. It was held
Monday and Tuesday, November 21 and 22.
Attending were France, The Netherlands, Germany, Japan, the UK, and
the US.
The US presented its position statement, which is as follows:
************************************************************************
The US is currently undertaking two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Within the United States, there is no demand
for another Lisp standard at this time.
The current activity of WG16 is to develop a standard for a dialect of
Lisp directed at a community of users who are served neither by Common
Lisp nor by Scheme---that dialect is IsLisp. Although is is unlikely
that IsLisp will have major near term commercial significance within
the US, the US supports the IsLisp standardization effort as long as
it does not negatively affect standards for other dialects of Lisp.
In particular, the US feels that it is important not to have two
standardized dialects of Lisp that are nearly identical unless one is
a strict subset of the other. Having two such similar but different
dialects weakens the position of users who have come to depend on one
of the dialects.
The US believes that the primary focus of standardization is to codify
existing practice to support the creation and delivery of portable
software. Thus, the major focus of the US standardization efforts is
to provide stability to the community of Common Lisp and Scheme users.
Of secondary importance are the invention of new Lisp dialects and the
standardization of Lisp dialects or features not in common usage. The
US therefore agrees with the ISO goal of a near term standard in the
1990 time frame along with longer range consideration of future
dialects and features.
Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). In each of these
countries there are companies whose customers depend on portable
software written in Common Lisp. The future of these companies thus
depends on having a Common Lisp standard.
The US believes that Common Lisp is a valid candidate for
international standardization both because it is used internationally
and also because it is a mature and stable dialect. Common Lisp has
been under design and specification for 8 years. Commercial quality
implementations of Common Lisp have been available for 4 years. The
near term standardization of ISO Common Lisp would have substantial
positive impact on the acceptance of existing commercial Lisp
implementations and on the viability of future Lisp dialects as
vehicles for emerging applications.
For these reasons, the US proposes the development of an ISO standard
for Common Lisp. Furthermore, the US proposes that WG16 request X3J13
to prepare the ISO draft standard for Common Lisp. The ISO Common
Lisp draft and the ANSI Common Lisp draft should be identical. The US
believes such a draft standard could be developed by December 1989.
The US also believes the development of an ISO standard for Common
Lisp is within the charter of WG16, which endorses the standardization
of multiple dialects of Lisp. At some point in the future, it may be
appropriate to develop an ISO standard for Scheme.
Looking beyond near term standardization, the US feels that an
important task for WG16 is working towards a next generation dialect
of Lisp, and this can be accomplished by drawing on the lessons
learned from existing dialects of Lisp.
************************************************************************
In addition, we proposed the following resolution:
************************************************************************
The U.S. proposes the following ISO WG16 resolution:
It is important to affirm and strengthen the position of the
international community of users who depend on Common Lisp. It is
also imperative that an international standard for Common Lisp must be
subject to international review and revision.
ISO WG16 resolves to proceed with an ISO Common Lisp standardization
process in the following manner:
* WG16 requests X3J13 to produce an ISO draft standard for Common
Lisp in accordance with SC22 synchronization principles for national
body development.
* The X3J13 drafting procedure will accommodate international public
review as well as U.S. public review. X3J13 will establish a schedule
to allow processing of all public comments.
* The timetable for forwarding a draft for circulation by WG16 is
December 1989. The U.S. should make every effort to meet this
schedule.
* X3J13 will inform WG16 of its schedules and progress.
************************************************************************
The German Delegation also had a written position statement. It is as
follows:
************************************************************************
The Position of DIN concerning LISP standardization
Herbert Stoyan
University of Konstanz
November 18, 1988
1. Our Goals
When the LISP-standardization process started we were optimistic to reach a
quick result. Now we have to change our feeling. It will take longer than we
have imagined. To speed up the process we want to change some of our position
statements made in Paris.
First, we voted for CommonLISP as a starting point for standardization. We
want to change this commitment into an open one. We join the US that one of
Scheme or CommonLISP (but not both) should be used.
Second, we made a vote for desirable characteristics of the standard. We
regret that not all points went as we desired. But the issues seem to be
mixed: There are language issues and report issues.
Before all the points, we should all agree that standardization is only
partially a language definition activity. We should standardize an existing
language. Therefore we don't like anymore the list of default values for
language components. If we still intend to follow this direction we get
everything but a language which is usable. We don't feel that this was a good
idea. DIN will accept any proposal for a LISP standard and check every part
of it - not only functional objects etc.
Obviously, the goal of standardization is portability. Therefore this issue
deserves most attention. We got here the right mark. The next issue of
standardization seems to be processor conformity. We would like to change our
figure `6' into a `2'. We believe the conformity must be provable: Without a
proof procedure for conformity our work is not complete. Especially, there
has to be a test suite.
The standard report must be technical clear. Therefore a clear semantics is
important. It is the way to achieve portability. We ranked this topic with
`3' and support this vote again. The standard report has to be
understandable. An important means to achieve this is a simple semantics. We
miss understandability as characteristics and again want to stress our figure
`4' here.
A standard report has to be usable. That means, it should be well organized,
it should not be too voluminous, it should be use not too many references to
other parts. Maybe this was meant by `Ease of learning'. We believe that
this characteristic is only an indicator for this quality of the standard.
Therefore we want to change our figure of `12' into a `5'.
Now, concerning the language. A language to be standardized must be
interesting. That must be already - we cannot change it. May be this is what
was meant as `Power'. We want to rank this point at first place in the
language goals we have. Power does not mean to provide everything. A
language which is too large and complex has no power and will not be
appealing. History of programming languages proves that baroque languages
will not last for long. Therefore we want to vote for `Compactness' - but it
is not in the list of characteristics.
If a language is big only because of many concepts which enable variations of
expressions for one and the same thing then the language is defined badly. If
the language contains elements which cannot be combined it should be regarded
as a family of languages. Both dimensions are called orthogonality. We want
to vote for `Orthogonality' - but cannot find it.
There are characteristics of implementations. Issues like efficiency,
consistency interpreter/compiler, stability etc. come in mind. They are goals
for implementors. Good implementors will achieve them - bad implementors wil
fail. These are not goals of standardization.
Ease of implementation is a goal which is always fulfilled with LISP. The art
is to find a way to quality.
2. The Situation
Our original proposal was to standardize a kernel of LISP with parts everybody
will accept readily. This work could be done in 18 month. But there are not
many countries to support this approach.
Richard Gabriel made the point that three languages should not be
standardized. We adopt this position. We have to ask who moved us in the
position where this danger is to be faced. Obviously, it is the pair of
US-activities. It was clear to ANSI that CommonLISP is not ready for
standardization. A de-facto standard ist not a true standard. We want not
decide without studying the latest draft of CommonLISP if it achieved enough
quality. Furthermore, we have the feeling that the activity for standardizing
Scheme was started to contravene the European desire for a clean LISP kernel.
3. Our Proposal
ISO is not an organisation for creating new languages. The maximal thing we
should plan is to change a presented language somewhat. The French have
exposed the three level approach. There seems nobody (with exception of DIN)
who likes the idea.
Therefore: We propose to take the draft reports of CommonLISP and Scheme
and check them for quality of being standardized. If they both have the
quality, we should standardize both of them with ISO. If only one has
the quality we should take this one. If none of the has the quality we
should generate a list of required changes and wait for better drafts. In the
meantime other member bodies are invited to define LISPs which deserve
standardization.
************************************************************************
In summary, they commented that the current ISO process does not seem
to be converging on a standard quickly enough, and that a short-term
standard can produced only by working with an existing dialect and
draft. They proposed that drafts for X3J13 Common Lisp and IEEE Scheme
be considered and measured against several criteria. These are that
the draft be clear and unambiguous, not unacceptably long (< 300 pages
was suggested), and precisely stated. The languages ought to be as
crisp and orthogonal as possible (that is, minimal redundant
features). The German Delegation proper consisted of Klaus Daessler
(Siemens), Dieter Kolb (Siemens), and Herbert Stoyan (University of
Konstanz). Kolb favors Common Lisp and the other two favor Scheme, but
the German position allowed for both to be selected and standardized
by ISO.
No other delegation had a written position statement. The Japanese
Delegation consisted of Professor Ito and Mr Kurokawa. Professor Ito
is primarily concerned about CLOS, but after private discussions I
learned that because of lack of study he did not understand it, and
the expert group that advises him consists of object-oriented
programming researchers who press their own ideas on him.
The French Delegation consisted of Jerome Chailloux and Greg Nuyens.
They responded by remarking that the US position represented a
``preposterous'' change in position by the US and directly
contradicted the agreed-upon work item. This work item was the AFNOR
(French) position which was to standardize a Common-Lisp-like dialect
with no packages, simple lambda-lists, simple arrays, generic
functions without classes, a different multiple value system, and a
different syntax for specials. The US argued that this plan was never
voted on because the convener would not allow it: He exaplined that
because it was a technical proposal, it was subject to discussion as
are all other technical points.
The US further remarked that the US position allowed for multiple
standardized dialects, but the convener denied this was possible under
the current work item and suggested we could try introducing a second
work item.
The French delegation contended that the US plan was to block the ISO
process. They were right in the limited sense that I threatened to
block the standardization of any dialect of Common Lisp that was
neither a superset nor a subset of Common Lisp.
I should point out that the French have formally asked SC22 (the
parent group of WG16) whether naming the resulting dialect ``IsLisp''
was allowed because the original work item stated that a standard for
``Lisp'' was being produced. The French commented that the US voted
``yes'' on the work item and that our comment about the name was
irrelevant. Jerome Chailloux's company, ILOG, has a contract from
ESPRIT to produce a draft of ``ISO Lisp.'' In fact, an ESPRIT catalog
we saw stated that the draft had been produced by ILOG in 1987 and was
available on request. However, to our knowledge, there is no ESPRIT
draft document of ``ISO Lisp''. All documents produced by AFNOR and
ILOG refer to ``ISO Lisp.''
As an aside, Chailloux pointed out that he oversees a lot of the
ESPRIT work on AI and that he would not allow any contractor to
use Common Lisp, only ISO Lisp. ILOG advertizes that ISO Lisp will
be available in the first half of 1989 (Beta available in December).
He told Dussud that he would ``have the Germans back in line by
December 15'' (which is the next EuLisp meeting).
The convener declared that discussion on this topic was deadlocked
until AFNOR could meet to decide their response to the US and German
position statements, which would not be until after the Hawaii
meeting. However, the convener told Mathis in private that he did not
want to go to Hawaii and was trying to find a way to cancel the
meeting. The convener also threatened to report failure to SC22 based
on his opinion that a consensus is not possible.
The US delegation agreed to ask X3J13 and the IEEE Scheme groups
whether they were willing to submit drafts under the German proposal.
While so agreeing, we pointed out that the convener was acting as if
the German position would be accepted. I pointed out that the US had
not withdrawn its proposed resolution.
The US delegation repeatedly commented that the US position was
intended to support Common Lisp users and was not intended to prevent
other distinct standards from being established to serve other
communities.
I expect that the word from AFNOR to the European community will be
that the US deliberately tried to block the ISO process, though I'm
not sure what reason he will provide for the US actions.
The second day of the meeting was devoted to three presentations:
Gabriel presented a report on the progress that US Common Lisp vendors
had made in the area of delivery of applications written in Common
Lisp. Mr Kurokawa presented a report on Japanese activity on
provisions within Common Lisp for international character sets. Thom
Linden presented the latest X3J13 work on the same topic. In
addition, the U.S. was asked to present the current WG16 status on
character handling at the next SC22 meeting.
The next ISO meeting is in March in Fairfax, Virginia.
-rpg-
∂02-Dec-88 2351 X3J13-mailer re: ISO meeting report
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 2 Dec 88 23:50:31 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA29272; Sat, 3 Dec 88 01:32:29 EST
Received: by mcvax.cwi.nl via EUnet; Sat, 3 Dec 88 07:05:56 +0100 (MET)
Received: by inria.inria.fr via Fnet-EUnet; Sat, 3 Dec 88 00:19:19 +0100 (MET)
Date: Sat, 3 Dec 88 00:19:19 +0100
From: mcvax!inria.inria.fr!chaillou@uunet.UU.NET (Jerome Chailloux)
Message-Id: <8812022319.AA10635@inria.inria.fr>
To: x3j13@sail.stanford.edu
Subject: re: ISO meeting report
Dear X3J13 members,
as an X3J13 Observer, I have several remarks on the Richard Gabriel's report
on the last WG16 meeting, held in Brussels the 21st and 22nd of November 88.
This report contains mistakes and doesn't reflect the many discussions
actually held during the meeting following the new ANSI position and the
DIN proposal. Please ask ANSI to distribute the official report of the
third meeting of WG16 to the members of X3J13.
But in addition of the incompleteness, there are some large mistakes in the
Mr Gabriel's report that I have to correct immediately:
1) the name of the standard
"I should point out that the French have formally asked SC22 (the
parent group of WG16) whether naming the resulting dialect ``IsLisp''
was allowed because the original work item stated that a standard for
``Lisp'' was being produced. The French commented that the US voted
``yes'' on the work item and that our comment about the name was
irrelevant."
False! This issue has been discussed at the first meeting at Paris. One
can read in the "Draft report of the 1st meeting of ISO/IEC JTC1/SC22/WG16
LISP," page 7 which is the official document WG16 Lisp N 12, which has been
approved at the second meeting at Snowbird:
"...
After several rounds of straw votes ISLISP was accepted.
The Secretariat was asked to let ISO Central Secretariat
in Geneva know such a change compared to the initial title
of the New Work Item.
..."
The AFNOR delegation has only asked if ISO in Geneva had given an answer.
2) ESPRIT
"Jerome Chailloux's company, ILOG, has a contract from
ESPRIT to produce a draft of ``ISO Lisp.'' In fact, an ESPRIT catalog
we saw stated that the draft had been produced by ILOG in 1987 and was
available on request. However, to our knowledge, there is no ESPRIT
draft document of ``ISO Lisp''. All documents produced by AFNOR and
ILOG refer to ``ISO Lisp.''"
Wrong! and not discussed at all at the Brussels meeting which was obviously
not the right place to discuss that! ILOG has no Esprit contract to
produce a draft of ISO Lisp! If Mr Gabriel refers to the "Technical
Interest Group: Lisp" funded by the Esprit Program, please let him quote
the exact and complete description of this TIG (from the 1987 annual report
ISBN 92-825-8999-4). If you want to hear a fair explanation I would say:
Since 1986 the Esprit Program has funded a TIG, called "EuLisp", to
prepare the standardization of Lisp and to produce a draft to be proposed at
what is called now WG16. This TIG is funded on a per-person basis and has
nothing to do with companies (the majority of the participants are in fact
academic).
3) ESPRIT (again)
"As an aside, Chailloux pointed out that he oversees a lot of the
ESPRIT work on AI and that he would not allow any contractor to
use Common Lisp, only ISO Lisp."
Ridiculous! I am not in position to decide such policy. Please Mr Gabriel,
give the exact wording of the introductory speech of Mr Omnes (from the
EEC). He said that 30% of the Esprit II Program will use Lisp and that a
standard (preferably an ISO Standard) is warmly desired and that the
promotion of standards is in the charter of the Esprit Program.
4) ILOG Advertising
"ILOG advertizes that ISO Lisp will be available in the first
half of 1989 (Beta available in December)."
Can Mr Gabriel, give us the reference of the ILOG advertisement that he
refers to?
5) Next EuLisp Meeting
"He told Dussud that he would ``have the Germans back in line by
December 15'' (which is the next EuLisp meeting)."
Again, this is wrong! At the next EuLisp meeting in December, the different
representatives of the european national organisation of standardisation
will try to have a common position in regard with the work done at WG16
because, despite the fact than some members of ANSI claim the contrary, it
seems to many that the new ANSI position will give a significant change of
direction of the work of WG16. This "radical" change has to be
discussed at different member bodies and then at the EuLisp meeting,
which seems reasonable at an International Working Group.
Jerome Chailloux
AFNOR representative at ISO WG16.
∂05-Dec-88 1209 X3J13-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Dec 88 12:06:03 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 DEC 88 11:45:41 PST
Date: 5 Dec 88 11:45 PST
Sender: masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
from: CL-Cleanup@Sail.Stanford.edu
REPLY-TO: cl-cleanup@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
Line-fold: NO
Message-ID: <881205-114541-3846@Xerox>
This is the first of a number of issues for which we have prepared
new versions since the October meeting. There will be a hardcopy
mailing of issues and a ballot; details in a separate message later.
Ballot issues will also be available for anonymous FTP from host
arisia.xerox.com in the directory clcleanup/pending.
As usual, if you have any comments, questions, please respond
to CL-CLEANUP@Sail.stanford.edu rather than to the entire
X3J13 list.
!
Forum: Cleanup
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
References: Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
Functions: TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291
The type-specifiers:
ARRAY, SIMPLE-ARRAY, VECTOR, SIMPLE-VECTOR
COMPLEX
Related Issues: SUBTYPEP-TOO-VAGUE, LIST-TYPE-SPECIFIER
Category: CHANGE
Edit history: Version 1, 13-May-88, JonL
Version 2, 23-May-88, JonL
(typo fixes, comments from moon, rearrange some discussion)
Version 3, 02-Jun-88, JonL
(flush alternate proposal ["flush-upgrading"]; consequently,
move more of discussion back to discussion section.
Version 4, 01-Oct-88, Jan Pedersen & JonL
(reduce discussion, and "cleanup" wordings)
(Version 5 edit history missing)
Version 6, 6-Oct-88, Moon
(fix typos, cover subtypep explicitly, add complex,
change name of UPGRADE-ARRAY-ELEMENT-TYPE)
Version 7, 7-Oct-88, JonL (more name and wording changes)
Version 8, 8-Oct-88, Masinter (wording, discussion)
Version 9, 31-Oct-88, JonL (major re-wording to accommodate
recent discussion; esp. re-introduce and clarify "upgrading")
Problem description:
CLtL occasionally draws a distinction between type-specifiers "for
declaration" and "for discrimination"; see CLtL, section 4.5 "Type
Specifiers That Specialize" (p.45 and following) The phrase
"for declaration" encompasses type-specifiers passed in as the
:element-type argument to MAKE-ARRAY, passed in as the <result-type>
argument to COERCE, and used in THE and DECLARE type declarations. The
phrase "for discrimination" refers to the type-specifiers passed in as
the <type> argument(s) to TYPEP and SUBTYPEP.
One consequence of this distinction is that a variable declared to be of
type <certain-type>, and all of whose assigned objects are created in
accordance with that type, may still have none of its values ever satisfy
the TYPEP predicate with that type-specifier. One type-specifier with
this property is
(ARRAY <element-type>)
for various implementation dependent values of <element-type>. For
example, in most implementations of CL, an array X created with an
element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
(TYPEP X '(ARRAY T))
but (almost) never will it satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 5))).
This is entirely permissible within the scope of standardization on
MAKE-ARRAY, where an implementation is required only to construct up the
result out of "the most specialized [element] type that can nevertheless
accommodate elements of the given type [the :element-type argument]"
(see CLtL, p287). That is, an implementation may in fact only provide a
very small number of equivalence classes of element-types for storing
arrays, corresponding to its repertoire of specialized storage techniques;
and it is explicitly permitted to "upgrade" any element-type request into
one of its built-in repertoire (see also CLtL, p45, second and third
paragraphs under Section 4.5.)
As a practical matter, almost every existing implementation does some
serious upgrading of the :element-type argument given to MAKE-ARRAY.
Yet the difference between "for declaration" and "for discrimination"
has been very confusing to many people. Similarly, portability is
hindered when users do not know just how a given implementation does
upgrading.
The type specifier (COMPLEX <part-type>) also falls in the domain of CLtL
Section 4.5. Currently, only one implementation actually provides any kind
of specialized storage for complex parts; and in this case, the practical
matter is less urgent, since the kind of upgrading happening is so obvious
as to cause little or no confusion.
Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
Short Summary:
** Eliminate the distinction between type-specifiers "for declaration" and
"for discrimination". In short, change the meaning of array and
complex type specifiers in favor of the "for declaration" meaning.
** Change the meaning of TYPEP to be in accord with "for declaration"
meaning of type-specifiers.
** Add an implementation-dependent function that reveals how a given
type-specifier for array element-types is upgraded. Add another such
function that reveals how a given type-specifier for complex parts is
upgraded.
** Clarify that "upgrading" implies a movement upwards in the type-
hierarchy lattice; i.e., if <type> upgrades to <Type>, then
<Type> must be a super-type of <type>.
** Clarify that upgrading an array element-type is independent of any
other property of arrays, such as rank, adjustability, fill-pointers,
etc.
** Clarify how SUBTYPEP thus behaves on array type-specifiers.
** Define how SUBTYPEP behaves on complex type-specifiers.
Note that despite this issue's name, the detailed specifications herein
apply to the type system -- not to the behavior of MAKE-ARRAY, nor to how
arrays are actually implemented.
Details:
First, some definitions: Two type-specifiers <type1> and <type2> are said
to be "type-equivalent" if and only if each one specifies a subtype of the
other one. For example, (UNSIGNED-BYTE 5) and (MOD 32) are two different
type- specifiers that always refer to the same sets of things; hence they
are type-equivalent. But (UNSIGNED-BYTE 5) and (SIGNED-BYTE 8) are not
type- equivalent since the former refers to a proper subset of the latter.
Two type-specifiers <type1> and <type2> are said to be "type-disjoint"
if their specified intersection is null. For example, INTEGER and FLOAT
are type disjoint by definition (see CLtL p.33), and (INTEGER 3 5) and
(INTEGER 7 10) are type-disjoint because the specified ranges have no
elements in common.
*. Eliminate the distinction between types "for declaration" and "for
discrimination". In particular, elminate any such reference in the
discussion of array and complex type-specifiers; this would include
documentation patterned after the discussion in section 4.5, pp. 45-7,
especially the example on p.46 that says "See ARRAY-ELEMENT-TYPE".
Change the meaning of (ARRAY <element-type>), as well as any of the
subtypes of ARRAY (such as SIMPLE-ARRAY, VECTOR, etc.) in favor of the
"for declaration" meaning. Make the similar simplification for the
<part-type> specifiers in the COMPLEX type-specifier.
*. Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is not
*, to be true if and only if <x> is an array that could be the result
of giving <type> as the :element-type argument to MAKE-ARRAY. While
(ARRAY *) refers to all arrays regardless of element type, (ARRAY <type>)
refers only to those arrays that can result from giving <type> as the
:element-type argument to the function MAKE-ARRAY. Change the meanings
for (SIMPLE-ARRAY <type>) and (VECTOR <type>) in the same way.
Change the meaning of (TYPEP <x> '(COMPLEX <type>)) similarly. Thus,
(COMPLEX <type>) refers to all complex numbers that can result from
giving numbers of type <type> to the function COMPLEX, plus all other
complex numbers of the same specialized representation. Remember that
both the real and the imaginary parts of any such complex number must
satisfy:
(TYPEP <real-or-imag-part> '<type>).
*. Add the function UPGRADED-ARRAY-ELEMENT-TYPE of one argument, which
returns the element type of the most specialized array representation
capable of holding items of the given argument type. Note that except
for storage allocation consequences, it could be defined as:
(DEFUN UPGRADED-ARRAY-ELEMENT-TYPE (TYPE)
(ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))
Since element-type upgrading is a fundamental operation implicit in
almost every existing implementation of MAKE-ARRAY, the purpose of this
added function is primarily to reveal how an implementation does its
upgrading.
Add the function UPGRADED-COMPLEX-PART-TYPE of one argument that
returns the part type of the most specialized complex number
representation that can hold parts of the given argument type.
*. Clarify that "upgrading" implies a movement upwards in the type-
hierarchy lattice. Specifically, the type-specifier <type> must be
a subtype of (UPGRADED-ARRAY-ELEMENT-TYPE '<type>). Furthermore, if
<type1> is a subtype of <type2>, then:
(UPGRADED-ARRAY-ELEMENT-TYPE '<type1>)
must also be a subtype of:
(UPGRADED-ARRAY-ELEMENT-TYPE '<type2>).
Note however, that two type-disjoint types can in fact be upgraded into
the same thing.
Clarify that ARRAY-ELEMENT-TYPE returns the upgraded element type
for the array; in particular, any documentation patterned after
the sentence on p. 291 begining "This set may be larger than the
set requested when the array was created; for example . . ." should
be embellished with this clarification.
Similarly, the type-specifier <type> must be a subtype of
(UPGRADED-COMPLEX-PART-TYPE <type>).
*. Clarify that upgrading an array element-type is independent of any
other property of arrays, such as rank, adjustability, fill-pointers,
displacement etc. For all such properties other than rank this should
be obvious (since they are not expressible in the language of
type-specifiers); but note that unless it is also independent of rank,
it would not be consistently possible to displace arrays to those of
differing rank.
*. Clarify that SUBTYPEP on ARRAY type-specifiers is as follows:
For all type-specifiers <type1> and <type2> other than *, require
(ARRAY <type1>) and (ARRAY <type2>) to be type-equivalent if and only
if they refer to arrays of exactly the same specialized representation;
and require them to be type-disjoint if and only if they refer to arrays
of different, distinct specialized representations. This definition
follows that implicitly prescribed in CLtL.
As a consequence of the preceding change to TYPEP and of the definition
of UPGRADED-ARRAY-ELEMENT-TYPE, the two type specifiers
(ARRAY <type1>) and
(ARRAY <type2>)
are type-equivalent if and only if
(UPGRADED-ARRAY-ELEMENT-TYPE '<type1>) and
(UPGRADED-ARRAY-ELEMENT-TYPE '<type2>)
are type-equivalent. This is another way of saying that `(ARRAY <type>)
and `(ARRAY ,(UPGRADED-ARRAY-ELEMENT-TYPE '<type>)) refer to the same
set of specialized array representations.
This defines the behavior of SUBTYPEP on array type-specifiers; namely:
(SUBTYPEP '(ARRAY <type1>) '(ARRAY <type2>))
is true if and only if
(UPGRADED-ARRAY-ELEMENT-TYPE '<type1>) and
(UPGRADED-ARRAY-ELEMENT-TYPE '<type2>)
are type-equivalent.
*. Define SUBTYPEP on COMPLEX type-specifiers as follows:
For all type-specifiers <type1> and <type2> other than *,
(SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>))
is T T if:
1. <type1> is a subtype of <type2>, or
2. (UPGRADED-COMPLEX-PART-TYPE '<type1>) is type-equivalent
to (UPGRADED-COMPLEX-PART-TYPE '<type2>); in this case,
(COMPLEX <type1>) and (COMPLEX <type2>) both refer to the
same specialized representation.
The result is NIL T otherwise.
The small differences between the SUBTYPEP specification for ARRAY and
for COMPLEX are necessary because there is no creation function for
complexes which allows one to specify the resultant part type independently
of the actual types of the parts. Thus in the case of COMPLEX, we must
refer to the actual type of the parts, although a number can be a member
of more than one type; e.g., 17 is of type (MOD 18) as well as of type
(MOD 256); and 2.3f5 is of type SINGLE-FLOAT was well as FLOAT.
The form:
(SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
must be true in all implementations; but:
(SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
is true only in implementations that do not have a specialized array
representation for single-floats distinct from that for other floats.
Examples:
Let <aet-x> and <aet-y> be two distinct type specifiers that are
definitely not type-equivalent in a given implementation, but for which
make-array will return an object of the same array type. This will be
an implementation dependent search, but in every implementation that
the proposer has tested, there will be some such types; often,
(SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.
Thus, in each case, both of the following forms return T T:
(subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
(array-element-type (make-array 0 :element-type '<aet-y>)))
(subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
(array-element-type (make-array 0 :element-type '<aet-x>)))
To eliminate the distinction between "for declaration" and "for
discrimination" both of the following should be true:
[A]
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-y>))
Since (array <aet-x>) and (array <aet-y>) are different names for
exactly the same set of objects, these names should be type-equivalent.
That implies that the following set of tests should also be true:
[B]
(subtypep '(array <aet-x>) '(array <aet-y>))
(subtypep '(array <aet-y>) '(array <aet-x>))
Additionally, to show that un-equivalent type-specifiers that use the
same specialized array type should be equivalent as element-type
specifiers, the following type tests should be true:
[C]
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-y>))
Rationale:
This proposal legitimizes current practice, and removes the obscure and
un-useful distinction between type-specifiers "for declaration" and
"for discrimination". The suggested changes to the interpretation of
array and complex type-specifiers follow from defining type-specifiers
as names for collections of objects, on TYPEP being a set membership
test, and SUBTYPEP a subset test on collections of objects.
Current Practice:
Every vendor's implementation that the proposer has queried has a finite
set of specialized array representations, such that two non-equivalent
element types can be found that use the same specialized array
representation; this includes Lucid, Vaxlisp, Symbolics, TI, Franz,
and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
tests [A] and [C] part 2; this is a consequence of implementing the
distinction between "for declaration" and "for discrimination". Lucid
and Xerox both pass test [B], and the other implementations fail it.
The Explorer returns NIL for all six tests in [A], [B], and [C].
Allegedly, the PCLS implementation does no "upgrading"; each array
"remembers" exactly the type-specifier handed to the MAKE-ARRAY call
that created it. Thus the test cases are not applicable to PCLS,
since the precondition cannot be met (i.e., find two non-type-equivalent
type-specifiers that are non-trivially upgraded by make-array).
The TI Explorer offers specialized representation for complexes;
part types of SINGLE-FLOAT and DOUBLE-FLOAT are specialized.
Cost to Implementors:
This proposal is an incompatible change to the current language
specification, but only a small amount of work should be required in
each vendor's implementation of TYPEP and SUBTYPEP.
Cost to Users:
Because of the prevalence of confusion in this area, it seems unlikely
that any user code will have to be changed. In fact, it is more likely
that some of the vendors will cease to get bug reports about MAKE-ARRAY
returning a result that isn't of "the obvious type". Since the change
is incompatible, some user code might have to be changed.
Cost of non-adoption:
Continuing confusion in the user community.
Benefits:
It will greatly reduce confusion in the user community. The fact that
(MAKE-ARRAY <n> :ELEMENT-TYPE '<type>) frequently is not of type
(ARRAY <type>) has been very confusing to almost everyone.
Portability of applications will be increased slightly, since
the behavior of
(TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE <type>) '(ARRAY <type>))
will no longer be implementation-dependent.
Esthetics:
Reducing the confusing distinction between type-specifiers "for
declaration" and "for discrimination" is a simplifying step -- it is a
much simpler rule to state that the type-specifiers actually describe
the collections of data they purport to name. Thus this is a step
towards increased elegance.
Discussion:
This issue was prompted by a lengthy discussion on the Common Lisp
mailing list. See for example a series of exchanges started on Thu,
17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
under the subject line of "Types in CL". See also the exchange started
Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
under the subject line of "TYPEP warp implications"
Although the types STRING, BIT-VECTOR, SIMPLE-STRING, and
SIMPLE-BIT-VECTOR are subtypes of the ARRAY type, they are not
specifically discussed in this proposal. The reason is that
they are not type-specifiers "that specialize", but are merely
abbreviations as follows:
STRING == (VECTOR STRING-CHAR)
SIMPLE-STRING == (SIMPLE-ARRAY STRING-CHAR (*))
BIT-VECTOR == (VECTOR BIT)
SIMPLE-BIT-VECTOR == (SIMPLE-ARRAY BIT (*))
Thus their semantics could be affected only in an implementation that
doesn't support a specific "specialized storage" type for arrays of
bits and vectors of string-chars. But in fact, every CL implementation
must appear to support "specialized storage" for bit-arrays and strings,
even if it means nothing more than remembering the fact that such an
array was created with that element-type. This is required in order
for strings, bit-vectors, and bit-arrays to be disjoint datatypes
(see CLtL p.34; see also the definitions of BIT-ARRAY and STRING found
in CLtL p.293, Section 17.4, and in CLtL p.299.)
We considered the possibility of flushing the permission to "upgrade";
for example, it could be made a requirement that:
(ARRAY-ELEMENT-TYPE (MAKE-ARRAY <n> :ELEMENT-TYPE <type>))
always be equal to <type> (or, at least type-equivalent to <type>)
for all valid type specifiers <type>. This has several problems: it
increases the storage requirement for many kinds of arrays, and hides
a relevant part of the underlying implementation for no apparently
good reason. However, it would increase portability, since it would be
much more difficult, for example, to write a program that created an
array with one element-type, say, (UNSIGNED-BYTE 5), but operated on it
assuming a non-trivial upgraded element-type, say, (UNSIGNED-BYTE 8).
Under this proposal, it is valid for an implementation of MAKE-ARRAY
to have arrays "remember" the type-equivalence class of the original
:element-type argument; such an implementation would satisfy all of
the constraints listed above.
We considered a suggestion to restrict the set of "known" array element
types; this would gain portability at the expense of limiting the
language.
We considered leaving out of the proposal the addition of the two
functions UPGRADED-ARRAY-ELEMENT-TYPE and UPGRADED-COMPLEX-PART-TYPE.
But it was noted that every implementation of CL supports exactly
that functionality somewhere in its implementation of MAKE-ARRAY; and
exposing this to the user would be a good thing. Furthermore, the
existence of at least UPGRADED-ARRAY-ELEMENT-TYPE makes the clarifications
on "upgrading" and SUBTYPEP implications easier. Finally, there would
be no other way at all to pinpoint just how complex parts are upgraded,
since there is no type information available except for the actual
types of the parts.
Since this proposal contains the implication:
(ARRAY <type1>) is-type-equivalent-to (ARRAY <type2>)
==>
<type1> is-type-equivalent-to <type2>
then the question naturally arises "Does the reverse implication hold?"
That is, should two non-EQ but type-equivalent type-specifiers <type1>
and <type2> always give rise to the same array types? For example,
consider SHORT-FLOAT and SINGLE-FLOAT in an implementation where these
are type-equivalent (see CLtL section 2.1.3). One may desire to implement
(ARRAY SHORT-FLOAT) and (ARRAY SINGLE-FLOAT) differently. Say, for example
that the former is packed into 16-bit half-words, whereas the latter is
packed into 32-bit words; but for either kind of packing, the result of
AREF is an ordinary "single-float". The whole point of the type-specifier
to make-array is merely to specify a packing technique for "packed float"
arrays. This "krinkle", however, will not be addressed by the proposal
herein; it should simply be remembered that the implication above goes
only one way, and is not an "if-and-only-if" link.
∂05-Dec-88 1238 X3J13-mailer Another Report on ISO/WG16
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 5 Dec 88 12:37:53 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA18474; Mon, 5 Dec 88 15:36:53 EST
Received: by mcvax.cwi.nl via EUnet; Mon, 5 Dec 88 18:44:17 +0100 (MET)
Received: by inria.inria.fr via Fnet-EUnet; Mon, 5 Dec 88 14:39:02 +0100 (MET)
Date: Mon, 5 Dec 88 12:03:36 -0100
From: mcvax!poly!queinnec@uunet.UU.NET (Queinnec Christian)
Message-Id: <8812051103.AA26857@poly.poly.fr>
To: rpg@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
Subject: Another Report on ISO/WG16
I just received your *personal* report on the last ISO meeting,
you sent to x3j13, and want to make some remarks to it. First, you
have the right to write anything you want, but the incriminated people
have also the right to try to present their own perception. You mix up
official stuff with personal or private thoughts aiming, in my own
point of view, to confusion. I will then try to fix, as the convenor
of the WG16, some of the points you made.
> The French Delegation consisted of Jerome Chailloux and Greg Nuyens.
> They responded by remarking that the US position represented a
> ``preposterous'' change in position by the US and directly
> contradicted the agreed-upon work item. This work item was the AFNOR...
No! The New Work Item was the result of an international agreement
which still remains unaltered.
> ... (French) position which was to standardize a Common-Lisp-like dialect
> with no packages, simple lambda-lists, simple arrays, generic
> functions without classes, a different multiple value system, and a
> different syntax for specials.
This list of technical points was decided in Paris Meeting as a way to
proceed to standardize IsLisp on the basis of CLtL as already improved
by X3J13. As every technical point in the agenda, it can be discussed
at length or even reassessed (as in Snowbird).
> The US argued that this plan was never
> voted on because the convener would not allow it: He exaplined that
> because it was a technical proposal, it was subject to discussion as
> are all other technical points.
See above.
> The US further remarked that the US position allowed for multiple
> standardized dialects, but the convener denied this was possible under
> the current work item and suggested we could try introducing a second
> work item.
I continue to interpret the NWI as a chart to standardize only one
element of the Lisp family.
> The French delegation contended that the US plan was to block the ISO
> process. They were right in the limited sense that I threatened to
> block the standardization of any dialect of Common Lisp that was
> neither a superset nor a subset of Common Lisp.
> I should point out that the French have formally asked SC22 (the
> parent group of WG16) whether naming the resulting dialect ``IsLisp''
> was allowed because the original work item stated that a standard for
> ``Lisp'' was being produced. The French commented that the US voted
> ``yes'' on the work item and that our comment about the name was
> irrelevant.
The US comment (like any other comment) is not irrelevant. But since it
would be the first time that a language would be standardized under a
precise name and not its proper name, this proposal as well as the
name voted in the WG were submitted, not to SC22, but to ISO in Geneva.
> Jerome Chailloux's company, ILOG, has a contract from
> ESPRIT to produce a draft of ``ISO Lisp.'' In fact, an ESPRIT catalog
> we saw stated that the draft had been produced by ILOG in 1987 and was
> available on request. However, to our knowledge, there is no ESPRIT
> draft document of ``ISO Lisp''. All documents produced by AFNOR and
> ILOG refer to ``ISO Lisp.''
In the AFNOR documents as well as in the BSI documents, the `Lisp'
to be standardized in the WG is nicknamed 'ISO Lisp'. Until a formal
agreement by ISO of the name IsLisp, this one is sufficiently clear
as were ISO Pascal, ANSI C...
> As an aside, Chailloux pointed out that he oversees a lot of the
> ESPRIT work on AI and that he would not allow any contractor to
> use Common Lisp, only ISO Lisp. ILOG advertizes that ISO Lisp will
> be available in the first half of 1989 (Beta available in December).
> He told Dussud that he would ``have the Germans back in line by
> December 15'' (which is the next EuLisp meeting).
Is this a personal thought of Mr Richard P. Gabriel about Mr Jerome Chailloux ?
> The convener declared that discussion on this topic was deadlocked
> until AFNOR...
and BSI and Netherlands and other countries not present. I recall that
the precise topic debated here is related to the answer of the WG to
the proposed US resolution.
>... could meet to decide their response to the US and German
> position statements, which would not be until after the Hawaii
> meeting. However, the convener told Mathis in private that he did not
> want to go to Hawaii and was trying to find a way to cancel the
> meeting.
It probably would have been the case that I cannot attend the Hawaii
meeting (due to lack of funds) but this is not a reason to cancel
it: first, the secretary would have been there and second, I can
mandate someone to represent me at this precise meeting as currently
done in other WGs.
> The convener also threatened to report failure to SC22 based
> on his opinion that a consensus is not possible.
I was mandated by SC22 to lead the standardization work. In case of
failure i.e, if I fail to reach a consensus, I naturally have to
report it to SC22.
> The US delegation agreed to ask X3J13 and the IEEE Scheme groups
> whether they were willing to submit drafts under the German proposal.
> While so agreeing, we pointed out that the convener was acting as if
> the German position would be accepted. I pointed out that the US had
> not withdrawn its proposed resolution.
It is true that everybody acts as if the German point of view was the
main topic to be discussed. I guess it is a consensus ...
C.Queinnec
Convenor of the WG16.
∂05-Dec-88 1249 X3J13-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Dec 88 12:48:03 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 DEC 88 12:25:45 PST
Date: 5 Dec 88 12:25 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 4)
To: X3J13@sail.stanford.edu
From: CL-CLEANUP@Sail.Stanford.Edu
Reply-to: CL-CLEANUP@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
Line-fold: NO
Message-ID: <881205-122545-3938@Xerox>
Some parts of the original issue were separated out as we have
not yet arrived at a recommendation.
!
Forum: Cleanup
Issue: CLOSED-STREAM-OPERATIONS
References: CLOSE (CLtL p 332)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
8-Oct-88, Version 2 by Masinter
13-Oct-88, Version 3 by van Roggen
1-Dec-88, Version 4 by Pitman
5-Dec-88, Version 5 by Masinter (separate other issues)
Related Issues: STREAM-ACCESS, STREAM-INFO, INPUT-STREAM-P-CLOSED,
CLOSE-CONSTRUCTED-STREAMS, PATHNAME-STREAM
Problem Description:
The description of CLOSE is not completely clear about the functions
which are allowed to be performed on a closed stream.
On p332 it says:
``The stream is closed. No further Input/output operations may be
performed on it. However, certain inquiry operations may still
be performed, ...''
but the list of inquiry operations is not specified.
Proposal (CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY)
Clarify the behavior of the following functions on closed streams:
* STREAMP is unaffected by whether its stream argument is open or closed.
* If CLOSE is called on a stream which is open, it will return T.
However, if CLOSE is called on a stream which is closed, it
will succeed without error but the return value is not specified.
* PATHNAME is valid on either an open or closed stream. Since some
implementations cannot provide the truename of a file until the
file is closed, it would in principle be possible for PATHNAME in
some implementations to return more specific information after the
stream is closed. For consistency, however, PATHNAME is prohibited
from doing this. PATHNAME must return the same pathname after a
file is closed as it did before. (The passed proposal in issue
PATHNAME-STREAM still stands.)
* TRUENAME is valid on either an open or closed stream. Since some
implementations cannot provide the truename of a file until the
file is closed, it is permissible TRUENAME to return more specific
information after the stream is closed.
* MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY,
PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING,
FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING,
ENOUGH-NAMESTRING, and OPEN are valid on either open or closed streams.
For any of these operations, using a stream, S, as an argument
where appropriate is equivalent to using (PATHNAME s). See the
description of PATHNAME above to understand the consequences of this.
* PROBE-FILE and DIRECTORY are valid on either open or closed streams.
For either of these operations, using a stream, S, as an argument
where appropriate is equivalent to using (PATHNAME s). See the
description of PATHNAME above to understand the consequences of this.
In this case of these operators however, closed stream may well be the
most reliable arguments in some cases, since treatment of open streams
to the file system may vary considerably between implementations.
For example, in some operating systems, open files are written under
temporary names and not renamed until close and/or are held invisible
until a close is performed. In general, any code with an intent to be
highly portable should tread lightly when using PROBE-FILE or
DIRECTORY.
Rationale:
One can consider many characteristics of a stream to be independent of
the ability to do I/O. Being able to determine a stream's direction and
its name is often useful for debugging. A number of the descriptions in
CLtL imply (weakly) the ability to work on closed streams. Functions
such as OPEN and DIRECTORY don't really depend on the stream, but on
the name of the stream.
Current Practice:
At least two implementations differ in which functions are allowed to be
performed on a closed stream.
Cost to Implementors:
Unknown, but likely to be small in most implementations.
A nontrivial amount of work may be necessary if the pathname information
is held externally and is normally deleted when the stream is closed.
The implementation will have to copy the information at some time for later
inquiries.
Cost to Users:
Likely to be small; users of an implementation forced to change
by this proposal might have to make some modifications to make their
programs portable.
Benefits:
These clarifications will assist users in writing portable code.
Aesthetics:
Most people will probably see these clarifications as an improvement
in aesthetics.
Discussion:
There are some separate, but related, issues regarding what CLOSE
should do on composite streams or constructed streams such as
created by MAKE-BROADCAST-STREAM. These issues will be addressed
in a separate issue (CLOSE-CONSTRUCTED-STREAMS).
There was some discussion on whether INPUT-STREAM-P and OUTPUT-STREAM-P
should return "false" on a stream that had been closed. The issue
STREAM-ACCESS contains a proposal to add a function OPEN-STREAM-P
which might be useful for the same purpose. This issue was separated
out into a separate issue (INPUT-STREAM-P-CLOSED).
The other functions in proposal STREAM-ACCESS:PROVIDE should
work on closed streams.
The functions in STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS should
not be requred to work on closed streams.
∂05-Dec-88 1531 X3J13-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Dec 88 15:30:53 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 DEC 88 15:25:23 PST
Date: 5 Dec 88 15:25 PST
Sender: masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
From: CL-CLEANUP@Sail.stanford.edu
REPLY-TO: CL-CLEANUP@sail.stanford.edu
Subject: Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
cc: masinter.pa@Xerox.COM
Message-ID: <881205-152523-4432@Xerox>
!
Forum: Cleanup
Issue: DECLARE-FUNCTION-AMBIGUITY
References: CLtL pp 43 (Table 4-1), 158-159
Issue FUNCTION-TYPE (passed X3J13/June 1988)
Category: CHANGE
Edit history: #1, 21 Sept 1988, Walter van Roggen
#2, 29 Sept 1988, Walter van Roggen (renamed; lessened ambiguity)
#3, 30-Sep-88, Masinter
#4, 5-Dec-88, Masinter (append Oct x3j13 comments)
Problem description:
CLtL permits confusing and ambiguous FUNCTION declarations. One can say
(DECLARE (FUNCTION F (VECTOR INTEGER) T))
to indicate that the function binding for F is of a certain type. Yet
one can also say
(DECLARE (FUNCTION X Y Z))
to indicate that the variables X, Y, and Z have values which are functions.
The former is an abbreviation for
(DECLARE (FTYPE (FUNCTION (VECTOR INTEGER) T) F))
The latter is an abbreviation for
(DECLARE (TYPE FUNCTION X Y Z))
The ambiguity arises in a case like
(DECLARE (FUNCTION F NIL STRING))
However, it would be an error to declare the type of the constant NIL to be a
FUNCTION, so technically there is no ambiguity--there is just a peculiar
special case.
Using the same declaration for two completely different purposes can lead
to confusion among people writing or reading such code.
It is now more useful to declare that variables have a value which
is of type FUNCTION, since the type FUNCTION has a more well-specified
meaning.
Proposal (DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION)
The declaration (FUNCTION name argtypes valtypes) is no longer permitted
to be an abbreviation for (FTYPE (FUNCTION argtypes valtypes) name).
The declaration (FUNCTION var1 var2) would just be an abbreviation for
(TYPE FUNCTION var1 var2).
Rationale:
Continuing to allow all the predefined atomic type specifiers as declaration
abbreviations for (TYPE type var1 var2 ...) is simpler for users to understand.
In other words, all the normal type declarations describe variable bindings;
only the FTYPE declaration describes function bindings. This is a more
uniform solution than making an exception to table 4-1.
Since the old use of the FUNCTION declaration for function bindings was just
an abbreviation for the FTYPE declaration, no expressivity is lost.
Furthermore one is able to say that a variable's value is of type FUNCTION,
something that hadn't been clearly possible without using the TYPE declaration.
Current Practice:
Many current implementations treat FUNCTION declarations
only as abbreviations for FTYPE declarations, primarily because
the proposal FUNCTION-TYPE has not been widely implemented.
Cost to Implementors:
Likely to be small to those implementations that heed these kinds of
declarations; none for those that don't.
Cost to Users:
Existing uses of the FUNCTION declaration for function bindings will need
to be changed to FTYPE declarations.
Cost of Non-Adoption:
People will continue to be confused by function declarations.
Benefits:
A simpler language.
Esthetics:
Discussion:
Making it clear that only FTYPE declarations describe function bindings will
make it easier to add new kinds of declarations that support incremental or
additional descriptions, as is needed for describing methods.
Since all cases can be disambiguated after all, compatibility considerations
might deem this proposal to be unnecessary. However, making declarations
simpler and less confusing is possibly more important than compatibility.
There is no consensus on the cleanup committee.
Comments from October 1988 X3J13 meeting:
... opposed but not vehemently--the incompatible change is gratuitous
... prefer to document the
issue rather than change it."
... a number of implementations accidentally implement
this incorrectly. They first check the type table and then handle
the elaborate function declaration style. But, as it happens,
they never reach the code for the second case because function is
in the type table!
... Having both styles is worse than having either one or the other.
∂05-Dec-88 1641 X3J13-mailer Issue: DEFPACKAGE (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Dec 88 16:41:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 DEC 88 16:39:43 PST
Date: 5 Dec 88 16:39 PST
Sender: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFPACKAGE (Version 7)
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <881205-163943-4628@Xerox>
!
Issue: DEFPACKAGE
References: CLtL section 11.7.
Issue: IN-PACKAGE-FUNCTIONALITY
Issue: MAKE-PACKAGE-USE-DEFAULT
Issue: PACKAGE-DELETION
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 23-Mar-88, Moon, changes based on discussion
Version 3, 27-Sep-88, JonL
(remove :import, :shadowing-import; allow :export to work on
imported and inherited; update references to in-package, etc.)
Version 4, 1-Oct-88, Masinter
Version 5, 6-Oct-88, Moon
Version 6, 6-Oct-88, JonL (little nits)
Version 7, 2-Nov-88, JonL
(incorporate further discussion; simplify handling of
syntactic errors; specify ordering constraints).
Problem description:
Many users incorrectly think that package operations can be performed
in any order. CLtL (p.192) contributes to this misconception.
Programmers need direction on the ordering constraint, especially for
creating packages, since doing things out of order can lead to
confusing or even intractable problems.
If the definition of a package is scattered throughout a program as a
number of individual forms, it is very easy to read a symbol before the
package setup needed to read that symbol correctly has been accomplished.
Three examples: an inherited symbol that should have been shadowed might
be accessed; a single-colon prefix might be used for a symbol that hasn't
yet been exported; an internal symbol might be created afresh where a
symbol that will later be imported or inherited was intended. These
problems can be difficult to understand or even to recognize; in some
cases it is difficult or impossible to correct the situation in the
same Lisp image.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. In the description below,
'package-name' and 'symbol-name' can be a symbol or a string; if a
symbol, only its name matters, not what package it is in.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is a list of a keyword and arguments. Nothing in a
DEFPACKAGE form is evaluated.
Standard options for DEFPACKAGE are listed below. Except for :SIZE,
options may appear more than once (this is useful primarily for
:IMPORT-FROM and :SHADOWING-IMPORT-FROM).
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified names.
(:USE {package-name}*)
The package is to "use" the other designated packages; that is,
it will inherit from them. The default value for this option
should be the same as it is for MAKE-PACKAGE (also see the issue
MAKE-PACKAGE-USE-DEFAULT).
(:SHADOW {symbol-name}*)
Create the specified symbols in the package being defined,
making them shadows, just as the function SHADOW would do.
(:SHADOWING-IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package, import
them into the package being defined, and place them on the
shadowing symbols list. In no case will symbols be created in
any package other than the one being defined; a continuable error
is signaled if no symbol is accessible in the package named
package-name for one of the symbol-names.
(:IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package and import
them into the package being defined. In no case will symbols be
created in a package other than the one being defined; a continuable
error is signaled if no symbol is accessible in the package named
package-name for one of the symbol-names.
(:EXPORT {symbol-name}*)
Find or create symbols with the specified names and export them.
Note an interaction with the :USE option, since inherited symbols
can be used rather than new ones created; note also an interaction
with the :IMPORT-FROM and :SHADOWING-IMPORT-FROM options, since
imported symbols can be used rather than new ones created.
(:INTERN {symbol-name}*)
Find or create symbols with the specified names. Note an
interaction with the :USE option, since inherited symbols
can be used rather than new ones created. This option is useful if
an :IMPORT-FROM or a :SHADOWING-IMPORT-FROM option in a subsequent
call to DEFPACKAGE (for some other package) expects to find these
symbols accessible but not necessarily external.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
This is an efficiency hint only, so that the package's table will
not have to be frequently re-expanded when new symbols are added
to it (e.g., by reading in a large file "in" that package).
The order in which the options occur in a DEFPACKAGE form is irrelevant;
but since the effects of the entry-making options are context-sensitive,
the order in which they will be executed is as follows:
(1) :SHADOW and :SHADOWING-IMPORT-FROM
(2) :USE
(3) :IMPORT-FROM and :INTERN
(4) :EXPORT
Shadows are established first, since they may be necessary to block
spurious name conflicts when the use link is established. Use links are
established next so that :intern and :export may refer to normally
inherited symbols. The :export is done last so that it may refer to
symbols created by any of the other options; in particular, shadows and
imported symbols can be made external. Note also the prescription on CLtL
p.178 to cover the case of calling EXPORT on an inherited symbol.
DEFPACKAGE creates the package as specified and returns it as its value.
It has no other side effects; e.g., it does not alter the value of *PACKAGE*.
The function COMPILE-FILE should treat top-level DEFPACKAGE forms the
same way it treats the other package-effecting functions (see CLtL p.182).
If the specified name already refers to an existing package, then the
name-to-package mapping for that name is not changed. At most, the
existing package will be modified to reflect the new definition; it is
undefined what happens if the new definition is at variance with the
current state of that package. If one of the specified nicknames already
refers to an existing package, then an error is signaled just the same
as MAKE-PACKAGE would. See the issue PACKAGE-DELETION for undoing the
name-to-package mapping.
Some DEFPACKAGE errors are, however, purely syntactic.
(1) An error should be signaled if :SIZE appears than once.
(2) Since extended options might be allowed by other implementations,
an error should be signaled if an option is present that is not
actually supported in this implementation.
(3) The collection of symbol-name arguments given to the options
:SHADOW, :INTERN, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must
all be disjoint; additionally, the symbol-name arguments given to
:EXPORT and :INTERN must be disjoint. If either condition is
violated, an error should be signaled.
Name conflict errors will, of course, be handled by the underlying calls to
USE-PACKAGE, IMPORT, and EXPORT.
Examples:
;;; An example that "plays it super-safe" by using only strings as names;
;;; does not even assume that the package it is read in to "uses" LISP;
;; *never* creates any symbols whatsoever in the package that it is read
;; in to.
(LISP:DEFPACKAGE "MY-PACKAGE"
(:NICKNAMES "MYPKG" "MY-PKG")
(:USE "LISP")
(:SHADOW "CAR" "CDR")
(:SHADOWING-IMPORT-FROM "VENDOR-COMMON-LISP" "CONS")
(:IMPORT-FROM "VENDOR-COMMON-LISP" "GC")
(:EXPORT "EQ" "CONS" "FROBOLA")
)
;;; A similar call, mostly using symbols rather than strings as names.
;;; Expects to be read in to a package that "uses" LISP and *may* create
;;; random internal symbols in that package (such as MY-PACKAGE etc).
(defpackage my-package
(:nicknames mypkg :MY-PKG) ;remember CL conventions for case
(:use lisp) ; conversion on symbols
(:shadow CAR :cdr #:cons)
(:export "CONS") ;yes, this is the shadowed one.
)
Rationale:
The availability of DEFPACKAGE encourages putting the entire package
definition in a single place. It also encourages putting all the package
definitions of a program in a single file, which can be loaded before
loading or compiling anything else that depends on those packages; such a
file can be read in the USER package, avoiding any initial state issues.
In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Current practice:
Symbolics Common Lisp (SCL) has always had a DEFPACKAGE, and users
prefer it to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL
version of DEFPACKAGE has quite a few additional options, but none of
them appears to be necessary to propose for Common Lisp at this time.
This proposal is incompatible with Symbolics DEFPACKAGE in some ways
that will probably not cause major problems.
Cost to Implementors:
Small--DEFPACKAGE can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
Small, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
It has been suggested that the "Put IN Seven EXtremely Random USEr
Interface COmmands" mnemonic described in CLtL p.191 could be removed;
and with possibly a few exceptions, the special handling of them by
COMPILE-FILE could be removed. As this would be an incompatible change,
it is not part of this proposal. However, a new mnemonic can be offered,
to help remember the ordering constraints mentioned above:
I REmember Six USEr Interface Expressions
Each word in the sentence corresponds to one operation listed below:
I IN-PACKAGE ;"foot" to stand on
REmember REQUIRE ;ensure pre-requisite packages
Six SHADOW ;block multiple-inheritances
USEr USE-PACKAGE ;go for it!
Interface IMPORT ;bring in "foreign" symbols
EXpressions EXPORT ;a "face" to show to others.
It is noted that DEFPACKAGE cannot be used to create two "mutually
recursive" packages, such as:
(defpackage my-package
(:use lisp your-package) ;requires 'your-package' to exist first
(:export "MY-FUN"))
(defpackage your-package
(:use lisp)
(:import-from my-package "MY-FUN") ;requires 'my-package' to exist first
(:export "MY-FUN"))
However, nothing prevents one from using the package-effecting functions
such as USE-PACKAGE, IMPORT, and EXPORT to establish such links (which
ought to be very rare) after a more standard use of DEFPACKAGE.
The macroexpansion of DEFPACKAGE could usefully canonicalize the names
into strings, so that even if a source file has random symbols in the
DEFPACKAGE form, the compiled file would only contain strings.
Frequently additional implementation-dependent options take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.
Definition forms in Common Lisp usually just establish a name-to-object
mapping; there is little precedent for them to modify other global-context
state. For this reason, we didn't want DEFPACKAGE also to "go" into the
new package. If it did so, like IN-PACKAGE, then the following reasonable
file would become confused, because it wouldn't all be in one package:
(in-package "USER")
(defpackage "WATER" (:use "LISP") (:export "FISH"))
(defpackage "ALCHEMY" (:use "LISP" "PHLOGISTON) (:export gold))
Should the token 'gold' be read while in the USER package, or in the
the WATER package?
The issue IN-PACKAGE-FUNCTIONALITY recommends that IN-PACKAGE be
incompatibly changed to recognize only existing packages, not to create
them. IN-PACKAGE would then not accept any keyword arguments.
The function MAKE-PACKAGE might also be extended to take all the keywords
that DEFPACKAGE does. This could be the subject of a separate cleanup.
∂06-Dec-88 0810 X3J13-mailer Re: ISO meeting report
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Dec 88 08:10:08 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA08575; Tue, 6 Dec 88 08:12:45 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA01763; Tue, 6 Dec 88 08:09:24 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA08992; Tue, 6 Dec 88 08:09:57 PST
Message-Id: <8812061609.AA08992@suntana.sun.com>
To: rpg@sail.stanford.edu,
mcvax!inria.inria.fr!chaillou@uunet.UU.NET (Jerome Chailloux)
Cc: x3j13@sail.stanford.edu
Subject: Re: ISO meeting report
In-Reply-To: Your message of Sat, 03 Dec 88 00:19:19 +0100.
<8812022319.AA10635@inria.inria.fr>
Date: Tue, 06 Dec 88 08:09:54 PST
From: kempf@Sun.COM
We are disappointed by the apparent disarray in relations between
ISO and ANSI and that there will not be a joint meeting
in January.
We believe that it is important to continue research into Lisp language
semantics which differ from those of Common Lisp, especially in areas
where Common Lisp is weak. The results of such research, once they become
accepted practice, can often be fed back into the standardization process,
strengthening the technical base of the standard. But standardization efforts
are not the place for research.
The position in the US statement reflects pretty much
the state of industry with regard to the commercialization of Lisp.
There is not really any demand for a commercial Lisp other than Common
Lisp in the US at the moment. Since Sun, as is the case for other Lisp vendors,
operates in the international marketplace, an international standard for
Common Lisp is highly desirable, since it reduces the investment Sun needs
to make in developing and supporting Lisp and Lisp based tools. Nobody
here believes that Common Lisp is technically the "right" solution, but
the technical challenges facing commercial Lisp today are less in terms
of semantics and more in terms of implementation technology. We expect
to monitor developments in Scheme and ISO activity.
We hope that the ANSI/ISO split can be resolved as quickly as possible, so
that the enormous amount of work put into the Common Lisp standard by
X3J13 over the last 3 years can benefit the international Lisp community
as well, and that the technical expertese of the international Lisp
community can be brought to bear on the final stages of checking the
draft standard for correctness.
James Kempf, Sun Microsystems
Cris Perdue, Sun Microsystems
∂07-Dec-88 1425 X3J13-mailer January agenda items please
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Dec 88 14:25:09 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00440g; Wed, 7 Dec 88 14:22:42 PST
Received: by challenger id AA04360g; Wed, 7 Dec 88 14:18:52 PST
Date: Wed, 7 Dec 88 14:18:52 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8812072218.AA04360@challenger>
To: x3j13@sail.stanford.edu
Subject: January agenda items please
Please let me know if you have something to add to the agenda and how much
time you need.
Please remember the 2 week rule for voting. Things should be mailed by 12/14
to insure receiving 2 weeks before the meeting.
---jan---
∂07-Dec-88 1659 X3J13-mailer Issue: DESCRIBE-INTERACTIVE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Dec 88 16:59:15 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 15:52:50 PST
Date: 7 Dec 88 15:52 PST
Sender: masinter.pa@Xerox.COM
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
From: CL-cleanup@Sail.Stanford.edu
Subject: Issue: DESCRIBE-INTERACTIVE (Version 4)
reply-to: CL-CLEANUP@Sail.stanford.edu
line-fold: NO
Message-ID: <881207-155250-1594@Xerox>
This issue has two proposals, EXPLICITLY-VAGUE and NO.
Notes from Fairfax meeting...
"...thinks it's stupid to waste time on issues like this....others disagreed."
!
Issue: DESCRIBE-INTERACTIVE
References: DESCRIBE (p441)
Category: CLARIFICATION (EXPLICITLY-VAGUE) / CHANGE (NO)
Edit history: 12-Sep-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
19-Oct-88, Version 3 by Pierson, invert
15-Nov-88, Version 4 by Pierson, two-proposal version
Problem Description:
CLtL is not clear about whether DESCRIBE may be interactive.
While CLtL describes INSPECT as an interactive as an
interactive version of DESCRIBE, it doesn't make explicit
that DESCRIBE is non-interactive. In some implementations it is,
and in other implementations it is not.
Users of systems in which DESCRIBE is not interactive may presume
that it is safe to call DESCRIBE in a batch applications without
hanging the application, which can lead to problems.
Proposal (DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE):
Specify that DESCRIBE is permitted (though not required) to
require user input, and that such input should be negotiated
through *QUERY-IO*.
Descriptive information would continue to go to *STANDARD-OUTPUT*.
Test Case:
The following kind of interaction would be permissible in
implementations which chose to do it:
(DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
(SETF (GETHASH 'FOO *MY-TABLE*) 1)
(SETF (GETHASH 'BAR *MY-TABLE*) 2)
(SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
(DESCRIBE *MY-TABLE*)
#<EQ-HASH-TABLE 259> has 3 entries.
Do you want to see its contents? (Yes or No) Yes
Rationale:
This validates current implementations.
Current Practice:
Symbolics Genera asks some questions interactively when describing
some kinds of structured data structures, such as hash tables.
Since users can define their own DESCRIBE methods and took their cue
from the system, describing some user structures also require such
interactions.
Cost to Implementors:
None.
Cost to Users:
User code which depended on DESCRIBE running without user interaction
would have to be modified. Such code is not currently fully portable,
however.
Cost of Non-Adoption:
Users would not know the straight story about whether they should
expect interaction from DESCRIBE.
Benefits:
Implementations which don't do interactive querying in DESCRIBE only
because their not 100% sure it's kosher would be free to do it.
Aesthetics:
Some people might think it's not aesthetic for DESCRIBE to require user
intervention. Not saying whether it's permissible is probably less
aesthetic, though.
Proposal (DESCRIBE-INTERACTIVE:NO):
Specify that DESCRIBE is forbidden to prompt for or require
user input. Permit implementations to extend describe via keyword
arguments to prompt for or require user input as long as the default
action if no keyword arguments are supplied does not prompt for or
require user input.
This is an incompatible change for some implementations.
Test Case:
The following kind of interaction would be permissible in
implementations which chose to do it:
(DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
(SETF (GETHASH 'FOO *MY-TABLE*) 1)
(SETF (GETHASH 'BAR *MY-TABLE*) 2)
(SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
(DESCRIBE *MY-TABLE* :INTERACTIVE T)
#<EQ-HASH-TABLE 259> has 3 entries.
Do you want to see its contents? (Yes or No) Yes
Rationale:
DESCRIBE is the only hook a portable program has for providing
information about objects to the user. The potential interactive
functions of DESCRIBE are also likely to be available via INSPECT.
Current Practice:
Symbolics Genera asks some questions interactively when describing
some kinds of structured data structures, such as hash tables.
Since users can define their own DESCRIBE methods and took their cue
from the system, describing some user structures also require such
interactions.
Cost to Implementors:
Symbolics Genera and other non-conforming implementations will have
to change.
Cost to Users:
User code which depends on DESCRIBE running with user interaction
will have to be modified. Such code is not currently portable,
however.
Cost of Non-Adoption:
Users would not have any portable way to have progams inform the
user about object they are dealing with. This might be important in
traces and logs of portable progams or in portable debugging tools.
Benefits:
It will be easier to provide some types of portable functionality.
Aesthetics:
This simplifies the language slightly.
Discussion:
Pitman thinks it's important to clarify this issue, but he isn't fussy
about the particulars.
EXPLICITY-VAGUE proposal is the minimal proposal for compatibility
with current behavior.
Some members of the cleanup committee think that EXPLICITLY-VAGUE is
really a change from the intent of CLtL. However, the current
sentiment is to be less rather than more specific about the behavior
of debugging tools (25.3 of CLtL).
It might be possible to extend DESCRIBE to have additional
keywords (:VERBOSE, :INTERACTIVE-ALLOWED) to cover
additional behavior.
Pierson supports NO because he thinks it's important for there to be
some way for portable programs to present this sort of information
to the user. While the exact data and format presented is
implementation dependent and thus outside of the bounds of
standardization, the existance of such data is neither.
Moon opposes NO because "it creates extra work for implementors and
users of at least one implementation, for no compelling reason."
Moon suggested as a compromise only allowing DESCRIBE to require
user input from "interactive streams". Several other members of the
committee like this in principle but question whether it's feasible
since we have neither defined "interactive streams" nor provided any
portable way to tell if a stream is interactive.
∂07-Dec-88 1803 X3J13-mailer Issue: DOTTED-MACRO-FORMS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Dec 88 18:03:39 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 17:12:10 PST
Date: 7 Dec 88 17:11 PST
Sender: masinter.pa@Xerox.COM
to: x3j13@sail.stanford.edu
Subject: Issue: DOTTED-MACRO-FORMS (Version 3)
from: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881207-171210-2206@Xerox>
At the cleanup committee meeting prior in Fairfax, we decided to propose this version.
!
Issue: DOTTED-MACRO-FORMS
References: forms (p54), lists and dotted lists (pp26-27),
DEFMACRO (p145), destructuring macro arguments (p146)
Category: CLARIFICATION/CHANGE
Edit history: 28-Jun-88, Version 1 by Pitman (explicitly-vague vs allow)
01-Oct-88, Version 2 by Masinter (disallow)
15-Nov-88, Version 3 by Pitman (revive allow, flush disallow)
Problem Description:
CLtL is not explicit about whether macro forms may be dotted
lists.
p54 says that only certain forms are "meaningful": self-evaluating
forms, symbols, and "lists".
pp26-27 defines "list" and "dotted list". It goes on to say
``Throughout this manual, unless otherwise specified, it is an
error to pass a dotted list to a function that is specified
to require a list as an argument.''
p146 states that in DEFMACRO destructuring, ``the argument
form that would match the parameter is treated as a
(possibly dotted) list, to be used as an argument forms list
for satisfying the parameters in the embedded lambda list.''
It goes on to say that ". var" is treated like "&rest var"
at any level of the defmacro lambda-list.
Proposal (DOTTED-MACRO-FORMS:ALLOW):
Define that it is permissible for a macro form (or subform)
to be a dotted list when "&REST var" or ". var" is used to match
it. It is the responsibility of the macro to recognize and deal
with such situations.
Rationale:
Some implementations permit dotted lists in macro forms at toplevel.
Most or all implementations permit dotted lists in macro forms at
embedded levels. This proposal makes the language internally
consistent without requiring changes to existing code.
Also, there's no reason to unnecessarily restrict &REST since there
is no computational overhead and since there's no dispute about how
to interpret programmer intent in this gray area.
Test Case:
#1: (DEFMACRO MACW (&WHOLE W &REST R) `(- ,(CDR W)))
(MACW . 1) => ??
#2: (DEFMACRO MACR (&REST R) `(- ,R))
(MACR . 1) => ??
#3: (DEFMACRO MACX (&WHOLE W) `(- ,(CDR W)))
(MACX . 1)
(MACW . 1) => -1 under this proposal.
(MACR . 1) => -1 under this proposal.
(MACX . 1) is an error under CLtL semantics and is not
changed by this proposal. The reason it is an
error is that the argument pattern does not
match. The pattern is dictated by the arguments
-other than- the &WHOLE argument, so the pattern
is () and MACX cannot be called with any arguments.
Current Practice:
A. Some implementations bind W to (MACW . 1) in #1 and #3
and bind R to 1 in #1 and #2.
B. Some implementations bind W to (MACW . 1) in #3
and signal a syntax error in #1 and #2.
C. Some implementations signal a syntax error in #1, #2, and #3.
Symbolics Genera is such an implementation.
Cost to Implementors:
Some implementations would have to eliminate an error check.
Some implementations which try to use APPLY of a normal lambda
to accomplish part of the destructuring (in the non-recursive case)
would have to be slightly more careful.
Cost to Users:
None. This change is upward compatible.
Benefits:
People would know what to expect.
Aesthetics:
Mixed opinion: certainly it is better to specify whether they are
allowed or an error than to be vague.
Some feel that disallowing dotted macro forms helps catch syntax errors.
Some feel that allowing dotted macro forms makes the language more regular.
Discussion:
Goldman@VAXA.ISI.EDU raised this issue on Common-Lisp.
This issue came up primarily in the context of program-written programs;
a macro used in the program generated code might occasionally use
a dotted tail to a list to explicitly represent special conditions.
Allowing dotted macro forms may blur the data/code distinction too much,
particularly for people who are new to Lisp. On the other hand, some people
argue that the point of macros is to help blur that distinction. Macro
forms are data which must be translated to program, and only once the
program claims to be macroexpanded ought syntax restrictions be imposed.
This proposal was rewritten from `DISALLOW' to `ALLOW' after Steele pointed
out in a recent meeting that dotted lists are allowed in subforms and
that permitting them at toplevel would be the most internally consistent
interpretation.
Pitman supports DOTTED-MACRO-FORMS:ALLOW.
∂07-Dec-88 2058 X3J13-mailer Issue: EXPT-RATIO (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Dec 88 20:58:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 20:51:44 PST
Date: 7 Dec 88 20:51 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: EXPT-RATIO (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
from: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881207-205144-2665@Xerox>
!
Forum: Cleanup
Issue: EXPT-RATIO
References: CLtL pages 204 and 211
Category: CLARIFICATION
Edit history: Version 1, 4-Oct-88, by Aspinall and Moon
Version 2, 6-Oct-88, Masinter (very minor discussion)
Version 3, 31-Oct-88, Masinter (fix typo)
Problem description:
The comment (page 204, 2nd para) that "... an implementation [of expt]
might choose to compute (expt x 3/2) as if it had been written
(sqrt (expt x 3))" disagrees with the principal value definition on
page 211. See the example below for a case where the two disagree. We
believe the principal value definitions are consistent and reasonable,
therefore the implementation comment is wrong.
Proposal (EXPT-RATIO:P.211):
Clarify that (sqrt (expt x 3)) is not equivalent to (expt x 3/2)
and that page 211 rules.
Examples:
(defvar x (exp (/ (* 2 pi #c(0 1)) 3))) ;exp(2.pi.i/3)
(expt x 3) => 1 (except for round-off error)
(sqrt (expt x 3)) => 1 (except for round-off error)
(expt x 3/2) => -1 (except for round-off error)
There can be no question that
(expt x 3) ==> 1
because expt is single-valued with an integer second argument, and
(sqrt 1) ==> 1
definitely follows the principal branch of the square root function.
But (expt x 3/2) is defined as (exp (* (log x) 3/2)) (page 211).
(log x) ==> 2.pi.i/3
according to the definition of the logarithm's branch cuts on page 211
(which really comes down to the branch cuts of phase - page 210), so
(* (log x) 3/2) ==> pi.i
and
exp(pi.i) is -1.
Rationale:
We believe the principal value definitions are consistent and
reasonable, therefore the implementation comment is wrong.
Current practice:
Symbolics Genera 7.3 currently returns the wrong answer, following page
204 rather than page 211. Lucid Common Lisp, and
Envos Medley implement the proposal.
Cost to Implementors:
The obvious code changes in complex expt.
Cost to Users:
None.
Cost of non-adoption:
Self-contradictory language specification.
Benefits:
Users can better predict the branch cuts in expt.
Discussion:
Mathematical Explanation: When the expt function returns a complex result
in CL (Cartesian) form, the phase of the complex number is effectively
canonicalized. Information is lost, and that information is necessary to
specify upon which branch of the sqrt function the final result should lie.
Another way to put it would be that although
sqrt(expt(x,3)) = expt(x,3/2)
where expt and sqrt are the mathematical multi-valued functions, it is not
true that:
pvsqrt(pvexpt(x,3)) = pvexpt(x,3/2)
where pvexpt and pvsqrt denote the principal value versions of those functions.
∂07-Dec-88 2143 X3J13-mailer Issue: FORMAT-PRETTY-PRINT (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Dec 88 21:43:15 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 21:33:31 PST
Date: 7 Dec 88 21:33 PST
Sender: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
Subject: Issue: FORMAT-PRETTY-PRINT (Version 7)
cc: Masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881207-213331-2723@Xerox>
!
Issue: FORMAT-PRETTY-PRINT
References: FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category: CLARIFICATION
Edit history: Version 1 by Pierson 3/4/88
Version 2 by Pierson 5/24/88 (fix name typo)
Version 3 by Pierson 6/10/88 incorporate comments
Version 4 by Pierson 6/10/88 comments from Van Roggen
Version 5 by Masinter 2-Oct-88
Version 6 by Pierson 11/10/88 final nits
Version 7 by Pierson 11/15/88 "does" => "does not"
Problem description:
The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively. The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.
Proposal (FORMAT-PRETTY-PRINT:YES):
Specify that FORMAT does not rebind any of the printer control
variables (*PRINT-...) except as follows:
~A
Binds *PRINT-ESCAPE* to NIL.
~S
Binds *PRINT-ESCAPE* to T.
~D
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 10.
~B
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 2.
~O
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 8.
~X
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 16.
~R
Iff a first argument is specified, binds *PRINT-ESCAPE* to NIL,
*PRINT-RADIX* to NIL, and *PRINT-BASE* to the value of the first
argument.
Iff no aruments are specified, binds *PRINT-BASE* to 10.
~@C
Binds *PRINT-ESCAPE* to T.
~F,~G,~E,~$
Binds *PRINT-ESCAPE* to NIL.
Test Cases/Examples:
(LET ((TEST '#'(LAMBDA (X)
(LET ((*PRINT-PRETTY* T))
(PRINT X)
(FORMAT T "~%~S " X)
(TERPRI) (PRINC X) (PRINC " ")
(FORMAT T "~%~A " X)))))
(FUNCALL (EVAL TEST) TEST))
This should print four copies of the above lambda expression. The
first pair should appear identical and the second pair should appear
identical. The only difference between the two pairs should be the
absence of string quotes in the second pair.
Rationale:
FORMAT should interact with the printer control variables in a
predictable way. This proposal is one of the two simplest possible
definitions and provides the most flexibility to the user.
A major advantage of this proposal is that the following two
expressions are guaranteed to have exactly the same effect:
(FORMAT stream "~S" object)
(PRIN1 object stream)
Thus use or non-use of FORMAT becomes a purely stylistic matter.
Current practice:
Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
to NIL.
Cost to Implementors:
While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications. How does a pretty-printing ~A
interact with MINCOL, etc? How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?
Cost to Users:
Truely portable code shouldn't be affected because existing
implementations are inconsistent. Despite this, there are probably a
number of user programs in non-complying implementations which will
have to change whichever way this is decided.
Cost of non-Adoption:
The interaction of FORMAT and the printer control variables (especially
*PRINT-PRETTY*) will remain undefined. This will continue to make
portable Common Lisp programming harder than it need be.
Benefits:
Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.
Aesthetics:
The interaction between two related parts of output will be clarified
in a simple way.
Discussion:
It is important to specify exactly what of Common Lisp's special
variables get rebound by other functions and macros in Common Lisp.
This cleanup issue addresses the interaction of FORMAT and the
*PRINT- variables. There may be other similar interactions in
Common Lisp that need clarification.
Otherwise, code that depends on FORMATs action in one implementation
will not port to others that do not have the same behavior.
CLtL might change as follows:
Add a header "Printer Control Variables" before the description of
*PRINT-ESCAPE* on page 370.
Add the following paragraph to page 386 just before the paragraph
starting with "It is an error":
"The FORMAT function by itself never binds any of the printer
control variables. Specific FORMAT directives bind exactly the
printer control variables specified in their description. While
implementations may specify the binding of new, implementation
specific printer control variables for each FORMAT directive, they
may neither bind any standard printer control variables not
specified in description of a FORMAT directive nor fail to bind
any standard printer control variables as specified in the
description."
There was some discussion on whether *PRINT-BASE* should be bound for
~F, ~G, ~E, and ~$. This is not necessary because page 341 of CLtL
states that floating point numbers are always printed in base 10.
∂08-Dec-88 0613 X3J13-mailer Re: January agenda items please
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 8 Dec 88 06:13:03 PST
Date: 8 Dec 1988 09:10-EST
Sender: ROSENKING@A.ISI.EDU
Subject: Re: January agenda items please
From: ROSENKING@A.ISI.EDU
To: jlz@LUCID.COM
Cc: mathis@A.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 8-Dec-88 09:10:30.ROSENKING>
In-Reply-To: <8812072218.AA04360@challenger>
What is the official status of the ISO meeting, is it on or off ?
It appears, from monitoring the mail since the last ISO meeting,
that there are several issues which need to be worked out. Do our
ISO reps and chairman believe that we should abandon the meeting
or perhaps try to take the initiative to bring the ISO reps all
together to try to solve some of the problems. Members such as
myself who are outside of this loop can not appreciate the true
status of the situation.
∂08-Dec-88 1056 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 10:56:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 10:39:12 PST
Date: 8 Dec 88 10:38 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-103912-3821@Xerox>
!
Forum: Cleanup
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p. 27, 47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(incorporate comments from Scott Fahlman & others)
Version 3, 13-Feb-88 Masinter
Version 4, 2-Oct-88 Masinter (update references,
discussion)
Version 5, 14-Nov-88 Masinter (add to discussion)
Related issues: FUNCTION-TYPE-KEY-NAME,
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
REST-LIST-ALLOCATION
Problem description:
The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types. This type specifier uses a
syntax similar to the usual lambda list syntax to specify which types go
with which lambda list variables. However, this is actually of limited
usefulness in the context of a declaration, where one normally wants type
information about the actual arguments which can be passed to the function
rather than the lambda variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST. For the sake of consistency, it would seem
that the corresponding type given in the FUNCTION declaration must also be
LIST, but since this provides no information about the actual arguments,
some users/implementors have instead adopted the convention of supplying
the type of the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the
type specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST is the type of each actual argument, not the type of the
corresponding lambda variable.
Example:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must
be LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Most Common Lisp
implementations currently ignore FUNCTION type declarations. The only
examples found so far are in a text book on Common Lisp, which follows the
proposed syntax.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do
so. Probably only a small amount of code would have to be written/changed
in implementations that currently think that the &REST argument should be
LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must
be LIST will have to change their code. However, because this issue is so
unclear, the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
Debatable. One the one hand, since the argument type syntax used by the
FUNCTION type specifier mirrors normal lambda-list syntax, it would be
cleaner and less confusing to provide the type of the lambda variable
rather than the type of the actual arguments. However, considering the
types specified in the FUNCTION specifier to be the types of the actual
arguments rather than the types of the parameters as seen on the receiving
end makes the proposed semantics more palatable.
Discussion:
This issue provoked considerable debate in the cleanup committee and at
X3J13.
Many people objected to this proposal, and would prefer the alternative
that the type given after a &REST in a function declaration apply to the
value of the formal parameter rather than the actual arguments. This would
be even more useful if complex LIST type specifiers were part of Common
Lisp (as the proposal in issue LIST-TYPE-SPECIFIER might add) or if it were
possible to declare, for example, &REST {keyword integer}*.
Some additional arguments against this proposal are the apparent mismatch
between the external declarations of type and the internal ones. It might
be that this proposals presumes that rest lists are always lists, and the
following is illegal:
(DEFUN FOO (&REST X) X)
(APPLY #'FOO T)
which is not otherwise explicitly forbidden, but for which there is no
legitimate declaration.
∂08-Dec-88 1129 X3J13-mailer Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 11:29:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 11:10:31 PST
Date: 8 Dec 88 11:10 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-111031-3954@Xerox>
!
Issue: GET-MACRO-CHARACTER-READTABLE
References: CLtL p.361: COPY-READTABLE, SET-SYNTAX-FROM-CHAR, and
GET-MACRO-CHARACTER
CLtL p.364: GET-DISPATCH-MACRO-CHARACTER,
CLtL p.378: Example in middle of page
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 16-Nov-88, by JonL
Version 2, 8-Dec-88, by Masinter (fix typo)
Problem description:
The 'readtable' argument to GET-DISPATCH-MACRO-CHARACTER and to
GET-MACRO-CHARACTER must be of type READTABLE, without mention of
what happens when NIL is supplied. This may have been simply
an oversight, since it makes more sense for it to refer to values from
the standard readtable. Both COPY-READTABLE and SET-SYNTAX-FROM-CHAR
explicitly say that a NIL in the 'from-readtable' argument refers to the
standard readtable. Also, an example in the middle of the page, CLtL
p.378, supplies a NIL to GET-MACRO-CHARACTER, and is clearly intending
to access the standard readtable values.
Proposal (GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD)
Specify that a NIL readtable argument to GET-DISPATCH-MACRO-CHARACTER
and to GET-MACRO-CHARACTER mean the same thing it does for COPY-READTABLE,
and SET-SYNTAX-FROM-CHAR; namely a reference to the standard readtable.
Thus (GET-MACRO-CHARACTER <char> NIL) would be equivalent to
(GET-MACRO-CHARACTER <char> (COPY-READTABLE)), but without consing.
Test Cases:
(let ((standard-rt (copy-readtable))
(chars '(#\* #\= #\| #\A #\ #\( #\# #\1)))
;; Test Case 1
(dolist (char chars)
(assert (eq (get-macro-character char nil)
(get-macro-character char standard-rt))
() "Lose on character ~C" char))
;; Test Case 2
(dolist (char chars)
(assert (eq (get-dispatch-macro-character #\# char nil)
(get-dispatch-macro-character #\# char standard-rt))
() "Lose on #\# dispatch character ~C" char))
;; Test Case 3
(assert (eq (get-dispatch-macro-character #\# #\A nil)
(get-dispatch-macro-character #\# #\a nil))
() "Lose on #\# dispatch character ~C" char)
)
Rationale:
Probably was the original intent; somebody wants it; also see "Esthetics".
Current practice:
Symbolics and Xerox have already implemented the proposal; Lucid, VAXLISP,
and KCL stuck to the more rigid interpretation.
Cost to Implementors:
Trivial.
Cost to Users:
None.
Cost of non-adoption:
Minor worry about porting between implementations that support the
generalization and those that don't; minor worry about consing when
calling (COPY-READTABLE) to get at standard readtable semantics.
Performance impact:
See "Cost of non-adoption".
Benefits:
See "Cost of non-adoption".
Esthetics:
Increases parallel design among similar readtable functions.
Discussion:
This question was raised in the Common Lisp mailing last summer:
Date: 19 Jul 88 13:35
Subject: Question about readtable null arguments
From: quiroz%cs.rochester:EDU:Xerox
To: common-lisp%sail.stanford:EDU:Xerox
∂08-Dec-88 1147 X3J13-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 11:45:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 88 11:32:56 PST
Date: 8 Dec 88 11:30 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (Version 7)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-113256-4026@Xerox>
!
Forum: Cleanup
Issue: HASH-TABLE-PACKAGE-GENERATORS
References: Issue: DO-SYMBOLS-DUPLICATES
Category: ADDITION
Edit history: Version 1, 23-May-88 JonL
Version 2, 6-Oct-88 JonL (convert to "with" scoping).
Version 3, 7-Oct-88 JonL (mly's syntax for package iterator)
Version 4, 8-Nov-88 JonL (fix example; clarify some nits)
Version 5, 22-Nov-88 Moon (improve syntax for package iterator,
add examples, fix typos)
Version 6, 6-Oct-88 JonL (final nits)
Version 7, 8-Dec-88, Masinter (add comment to discussion)
Problem description:
The Iteration subcommittee would like the several iteration proposals to be
writable in portable Common Lisp code. Unfortunately, the only complete
access to hash-tables and packages is through MAPHASH and DO-SYMBOLS (and
DO-EXTERNAL-SYMBOLS and DO-ALL-SYMBOLS); none of these existing primitives
is satisfactory for building complex iteration clauses. In particular,
these primitives are fully packaged and do not allow control over the
individual operations of starting the iteration, stopping the iteration,
and advancing to the next step of the iteration.
Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER)
Add two new macros WITH-HASH-TABLE-ITERATOR and WITH-PACKAGE-ITERATOR
to the language as follows:
WITH-HASH-TABLE-ITERATOR ((<next-fn> <hash-table>) &body body) [Macro]
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return the items, one by one, from the hash-table which is obtained
by evaluating <hash-table> only once.
An invocation (<next-fn>) returns three values as follows:
1. a boolean indicating whether an entry is returned (T says yes)
2. the key item (of a <key, value> pair)
3. the value item (of a <key, value> pair)
After all entries have been returned [by successive invocations of
(<next-fn>)], then only one value is returned, namely NIL.
WITH-PACKAGE-ITERATOR ((<next-fn> <package-list> [Macro]
&rest <symbol-types>)
&body body)
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return symbols, one by one, from the packages that are elements
of the list which is obtained by evaluating <package-list> only once.
Each element of <package-list> can be a package or the name of a
package.
The order of symbols returned does not necessarily reflect the order
of packages in <package-list>. When <package-list> has more than
one element, it is unspecified whether duplicate symbols are
returned once or more than once. Even when <package-list> has only
one element, it is unspecified whether symbols inherited from
multiple packages are returned more than once. See the proposal
DO-SYMBOLS-DUPLICATES:ALLOWED.
As a convenience, the value of <package-list> can be a package or
the name of a package; this is equivalent to a list of one element.
An argument of NIL is treated as an empty list of packages.
The <symbol-types> subform consists of one or more symbols from the
set {:INTERNAL, :EXTERNAL, :INHERITED}. Their order does not
matter. The <symbol-types> subform is not evaluated. This controls
which symbols accessible in a package are returned:
:INTERNAL means the symbols that are present in the package,
but which are not exported;
:EXTERNAL means the symbols that are present and exported;
:INHERITED means the symbols that are exported by used packages
and that are not shadowed.
When more than one argument is supplied for <symbol-types>, then a
symbol is returned if its accessibility matches any one of the
<symbol-types> specified. WITH-PACKAGE-ITERATOR signals an error if
no <symbol-types> are specified or if a <symbol-type> not recognized
by the implementation is specified. Implementations are permitted to
extend this syntax by recognizing additional symbol accessibility types.
An invocation (<next-fn>) returns four values as follows:
1. a boolean indicating whether a symbol is returned (T says yes)
2. a symbol (accessible in one the indicated packages)
3. the accessibility type for that symbol; i.e. one of
:INTERNAL, :EXTERNAL, or :INHERITED
4. the package from which the symbol has been accessed.
After all symbols have been returned [by successive invocations of
(<next-fn>)], then only one value is returned, namely NIL.
The fourth return value is one of the packages present or named in the
<package-list> argument. The meaning of the second, third, and fourth
values is that the returned symbol is accessible in the returned package
in the way indicated by the second return value:
:INTERNAL ==> present, and not exported,
:EXTERNAL ==> present, and exported,
:INHERITED ==> not present (thus not shadowed) but inherited
from some used package.
It is unspecified what happens if any of the implicit interior state
of an iteration is returned outside the dynamic extent of the WITH-...
form (such as by returning some closure over the invocation form).
Any number of invocations of with-hash-table-iterator and
with-package-iterator can be nested, and the body of the innermost one
can invoke all of the MACROLET'ed macros, provided all those macros
have distinct names.
Examples:
The following function should return T on any hash-table, and signal
an error if the usage of 'with-hash-table-iterator' doesn't agree
with the corresponding usage of 'maphash'.
(defun test-hash-table-iterator (hash-table)
(let ((all-entries '())
(generated-entries '())
(unique (list nil)))
(maphash #'(lambda (key value) (push (list key value) all-entries))
hash-table)
(with-hash-table-iterator (generator-fn hash-table)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? key value) (generator-fn)
(unless more? (return))
(unless (eql value (gethash key hash-table unique))
(error "Key ~S not found for value ~S" key value))
(push (list key value) generated-entries))))
(unless (= (length all-entries)
(length generated-entries)
(length (union all-entries generated-entries :test #'equal)))
(error "Generated entries and Maphash entries don't correspond"))
t))
The following function should return T on any package, and signal
an error if the usage of 'with-package-iterator' doesn't agree
with the corresponding usage of 'do-symbols'.
(defun test-package-iterator (package)
(unless (packagep package)
(setq package (find-package package)))
(let ((all-entries '())
(generated-entries '()))
(do-symbols (x package)
(multiple-value-bind (symbol accessibility)
(find-symbol (symbol-name x) package)
(push (list symbol accessibility) all-entries)))
(with-package-iterator (generator-fn package
:internal :external :inherited)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? symbol pkg accessibility)
(generator-fn)
(unless more? (return))
(let ((l (multiple-value-list (find-symbol (symbol-name symbol)
package))))
(unless (equal l (list symbol accessibility))
(error "Symbol ~S not found as ~S in package ~A [~S]"
symbol accessibility (package-name package) l))
(push l generated-entries)))))
(unless (and (subsetp all-entries generated-entries :test #'equal)
(subsetp generated-entries all-entries :test #'equal))
(error "Generated entries and Do-Symbols entries don't correspond"))
t))
The following function prints out every interned symbol (possibly
more than once):
(defun print-all-symbols ()
(with-package-iterator (next-symbol (list-all-packages)
:internal :external)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? symbol) (next-symbol)
(if more?
(print symbol)
(return))))))
The following could be an acceptable definition of the function
MAPHASH, implemented by WITH-HASH-TABLE-ITERATOR"
(defun maphash (function hash-table)
(with-hash-table-iterator (next-entry hash-table)
(loop (multiple-value-bind (more key value) (next-entry)
(unless more (return nil))
(funcall function key value)))))
Rationale:
The particular way in which hash-tables and packages are represented
need not be standardized, or even exposed to the user. Yet a simpler
handle on them is needed for the various iteration paradigms to be written
in portable code. In fact, after these iterator macros are put into an
implementation, then MAPHASH and DO-<mumble>-SYMBOLS are trivial usages
of them; but no _efficient_ use of the current primitives will provide
the effect of the new macros, namely a form that _returns_ the elements
of a table "one by one".
Current Practice:
Nobody does it this way, but both Symbolics and Lucid are not far off.
Cost to Implementors:
Moderate. Possibly a couple day's to a week's work for an implementation
that has to start completely afresh. Something like this is already being
done by the standard package macros [CLtL, p187].
Cost to Users:
None.
Benefits:
Will provide a more basic primitive for iterating over hash-tables and
packages; will permit new iteration paradigms to be written in portable code.
Aesthetics:
All other things being equal, it is better to have more general primitives
than less general ones.
Discussion:
The Iteration Subcommittee supports this proposal (or, "used to" --
JonL 6-Oct-88).
One must be careful not to assume that the invocation (<next-fn>) is a
"generator" function call -- since <next-fn> is MACROLET'd in an
implementation dependent way, it could even turn into a special form like
(if something
(values nil)
(yet-another-function-call))
The scoping called for herein may not be quite so useful to the "generators"
style proposals; in particular they offer an interface wherein one may
create a "generator" function of indefinite extent that returns, one-by-one,
the elements of the table. The constrained scoping implicit in these
WITH-... macros is not so much for any kind of optimization, but rather
for coordination of such hash-table "locking" as may occur in multi-
processing implementations like Symbolics. Nevertheless, Dick Waters
thinks these macros should be put in anyway, since it clearly is a
requirement for a portable LOOP, and can be use in a limited context
(i.e., not "indefinite scope") for portable versions of ITERATE and OSS.
Of course, if an implementation _can_ support an indefinite extent for
a "generator" object returned out of the iterator forms, it is allowed
to do so by this proposal.
The following macro definitions show how Common Lisp's DO-mumble-SYMBOLS
macros could have been defined in terms of WITH-PACKAGE-ITERATOR. They
are intended as illustrative examples, not as new specifications of those
built-in Common Lisp facilities. [PARSE-BODY is as defined in Guy Steele's
"Clarifications" of 6-Dec-85.]
(defmacro do-symbols ((var &optional (package `*package*) result-form)
&body body
&environment env)
(multiple-value-bind (body decls docstring) (parse-body body env)
`(with-package-iterator (next-symbol (list ,package)
:internal :external :inherited)
(let (more? ,var)
,@decls
(loop
(unless (multiple-value-setq (more? ,var) (next-symbol))
(setq ,var nil)
(return ,result-form))
,@body)))))
(defmacro do-external-symbols ((var &optional (package `*package*) result-form)
&body body
&environment env)
(multiple-value-bind (body decls docstring) (parse-body body env)
`(with-package-iterator (next-symbol (list ,package)
:external)
(let (more? ,var)
,@decls
(loop
(unless (multiple-value-setq (more? ,var) (next-symbol))
(setq ,var nil)
(return ,result-form))
,@body)))))
(defmacro do-all-symbols ((var &optional result-form)
&body body
&environment env)
(multiple-value-bind (body decls docstring) (parse-body body env)
`(with-package-iterator (next-symbol (list-all-packages)
:internal :external)
(let (more? ,var)
,@decls
(loop
(unless (multiple-value-setq (more? ,var) (next-symbol))
(setq ,var nil)
(return ,result-form))
,@body)))))
-------
"Why not define <next-fn> as a local function as if defined by
FLET rather than a macro as if defined by MACROLET? "
"A macro gave more scope to the implememtation to optimize
without losing anything essential in these circumstances."
∂08-Dec-88 1524 X3J13-mailer Issue: HASH-TABLE-TESTS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 15:24:30 PST
Received: from Salvador.ms by ArpaGateway.ms ; 08 DEC 88 15:11:34 PST
Date: 8 Dec 88 15:06 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: HASH-TABLE-TESTS (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-151134-4673@Xerox>
!
Issue: HASH-TABLE-TESTS
References: CLtL, p382 (third paragraph), and p383
Issue EQUAL-STRUCTURE
Requires Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Category: Addition
Edit history: 26-Sep-88 Version 1 by JonL
8-Dec-88 Version 2 by Masinter
(as per cl-cleanup)
Problem Description:
A great many users try to coalesce two equivalent DEFSTRUCT instances,
or two equivalent pointer arrays, using hash tables; but they are rudely
awakened when they find out that EQUAL is not an appropriate test for
this case, and that there is no :test argument to MAKE-HASH-TABLE which
will "hash on non-tree structures".
Proposal: HASH-TABLE-TESTS:ADD-EQUALP
With the advent of the issue CONTAGION-ON-NUMERICAL-COMPARISONS, we
can expect EQUALP to be a true equivalence function, and thus a suitable
candidate for the :test function to MAKE-HASH-TABLE. Hash-tables will
come in four kinds, the difference being whether the keys are compared
with EQ, EQL, EQUAL, or EQUALP.
Examples:
> (defstruct foo a b c)
FOO
> (setq x (make-foo :a 1 :b 'b :c '(1 . 2))
x-copy (make-foo :a 1 :b 'b :c '(1 . 2)))
#S(FOO A 1 B B C (1 . 2))
> (setq y #(1 B (1 . 2))
y-copy (copy-seq y))
#(1 B (1 . 2))
> (setq ht-equal (make-hash-table :test 'equal)
ht-equalp (make-hash-table :test 'equalp))
#<Hash-Table BB1F7B>
> (progn (setf (gethash x ht-equal) t) (setf (gethash x ht-equalp) t)
(setf (gethash y ht-equal) t) (setf (gethash y ht-equalp) t))
T
> (gethash x-copy ht-equal)
NIL
NIL
> (gethash x-copy ht-equalp)
T
T
> (gethash y-copy ht-equal)
NIL
NIL
> (gethash (copy-seq y) ht-equalp)
T
T
>
Rationale:
Implementing hash-tables efficiently is not an easy task; it makes more
sense for this to be standardly available than for individual programmers
to keep trying to re-invent this obscure part of technology.
Current Practice:
Lucid's release 3.0 implements this proposal [some 2.1-level release
supported it "provisionally"]. Symbolics implementation is reputed
to be robust enough to implement this proposal trivially.
Cost to Implementors:
Moderate. Implementors have already dealt with EQUAL; the only tricky
part will be ensuring the implication:
"If 'a' is EQUALP to 'b', then 'a' and 'b' must lie in the
same collision chain in any given EQUALP hash table"
It has been suggested that merely linear searching a table is an acceptable
implementation technique for CL's hash-tables [although no serious
implementation limits itself thus] and that such tables have no "collision
chains"; but in fact, this is the degenerate case wherein all entries are
in the same collision chain, so the implication is trivially satisfied.
Some persons prefer to say that the "reprobe sequence will be the same for
the two items", rather than using the term "collision chain"; the meaning
is the same.
Cost to Users:
None. This is an entirely upwards-compatible addition.
Cost of non-adoption:
Continuing bug reports from users about why "hashing
doesn't work" when said user tries entering pointer-containing objects
other than cons cells into hash tables. Continuing delay in same
user's work until they figure out a new strategy for identifying
equivalent structures. More difficulty in debugging their alternatives.
Benefits:
Addresses one aspect of the difficult equivalence problem. Makes
hash tables more useful. Permits case-insensitive hashing
on strings [tables of type EQUAL are case-sensitive on strings];
another use is to allow = comparison for numbers
[tables of type EQUAL use EQL on numbers].
Aesthetics:
Reduces the discontinuity between basic equivalence functions and those
usable as equivalence relations in hash-tables.
Discussion:
With the rejection of all the issues related to EQUAL-STRUCTURE, there is
little or no hope that EQUAL will be "beefed up" to meet the expectations
of so many of the user community on compound structures. If one wants
a hash-table with a :test function that has fewer equivalence classes
(i.e., does more "coalescing"), then there is no alternative now except
to use the function EQUALP.
It would also be possible to extend hash tables to allow = or
STRING=, but those are not being proposed at this time.
∂08-Dec-88 1644 X3J13-mailer Issue: LCM-NO-ARGUMENTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 16:43:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 16:29:52 PST
Date: 8 Dec 88 15:45 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: LCM-NO-ARGUMENTS (Version 1)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-162952-4859@Xerox>
!
Forum: Cleanup
Issue: LCM-NO-ARGUMENTS
References: CLtL p. 202
Category: ADDITION
Edit history: Version 1, Guy Steele 10/17/88
Problem description:
CLtL incorrectly states that (lcm) should return infinity, and
therefore specifies that giving lcm no arguments is an error.
In point of mathematical fact, 1 is the identity for the lcm operation.
Proposal (LCM-NO-ARGUMENTS:1):
Define (lcm) to return the integer 1.
Examples:
(lcm) => 1
Currently the behavior in this case is implementation-dependent.
Rationale:
Doing what is mathematically right.
Current practice:
KCL signals an error.
Lucid Lisp returns 1.
Symbolics Common Lisp returns 1.
Cost to Implementors:
Pretty small (one-line fix).
Cost to Users:
None.
Cost of non-adoption:
Continued embarassment for Steele.
Performance impact:
Negligible.
Benefits:
Correct handling of a seldom-used boundary case.
Esthetics:
Mild improvement.
Discussion:
Mentioned in Steele's December 1985 "clarifications".
∂08-Dec-88 1643 X3J13-mailer Issue: LAMBDA-FORM (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 16:43:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 16:29:39 PST
Date: 8 Dec 88 15:30 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: LAMBDA-FORM (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-162939-4858@Xerox>
!
Forum: CLeanup
Issue: LAMBDA-FORM
References: LAMBDA (p59)
Related Issues: LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
02-Oct-88, Version 3 by Pitman
22-Nov-88, Version 4 by Masinter
Problem Description:
In Scheme, one writes not #'(LAMBDA ...) but just (LAMBDA ...).
Many Common Lisp programmers have asked for this feature.
It can be written by the user, but since it's a commonly asked
for feature, it would make sense for it to be in the standard.
Also, even though the definition is trivial,
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
it is difficult to offer this as an extension because then "portable
code" tries to define it, it will get a redefinition warning because
it will be clobbering the system's predefined definition.
[An implementation could shadow LAMBDA, but that, too, has associated
problems.]
Proposal (LAMBDA-FORM:NEW-MACRO):
Add a LAMBDA macro, which has equivalent effect to:
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
Rationale:
This is an upward-compatible extension which ``codifies current
practice'' in that it makes a commonly defined macro available
as a standard part of the language.
Test Case:
#1: (DEFUN ADDER (N) (LAMBDA (X) (+ X N)))
(FUNCALL (ADDER 5) 3) => 8
#2: (MAPCAR (LAMBDA (X) (+ X 3)) '(1 2 3)) => (4 5 6)
#3: (MACROEXPAND '(LAMBDA (X) (+ X Y)))
=> (FUNCTION (LAMBDA (X) (+ X Y)))
Current Practice:
Symbolics Genera implements NEW-MACRO.
Symbolics Cloe does not offer a LAMBDA macro because users who defined
their own in portable code complained that they were getting redefinition
warnings that CLtL had led them to believe shouldn't happen. [Ironically,
the redefinition warnings always came when they tried to define LAMBDA
in the way it was already defined!]
Many other Common Lisp implementations do not offer such a macro.
Cost to Implementors:
The cost is trivial. A portable definition is shown in the
problem description above.
Cost to Users:
No conversion cost. This change is basically upward compatible.
Cost of Non-Adoption:
There are no really major consequences of non-adoption.
Benefits:
It's been suggested that some people write '(LAMBDA ...) rather than
#'(LAMBDA ...) because it's less ugly, and then run into confusion
later. If they could just write (LAMBDA ...), some that use overly
superficial reasons for the choice of one notation over another might
accidentally select the primitive they should probably really be using.
Aesthetics:
In Scheme, the operator of a function invocation form has the same
evaluation semantics as the operands. In CL, however, the operator is
not evaluated in the same way that the operands are. This definition
of LAMBDA as a macro would obscure this difference. A novice Lisp
programmer might have a hard time understanding why the #' is
optional in
(MAP [#'](LAMBDA (POINT) (+ (POINT-X POINT) (POINT-Y POINT)))
POINT-LIST)
but is required in
(MAP #'SUM-OF-COORDS POINT-LIST)
This proposal "clutters" the language because it makes the syntax
more complex. LAMBDA is then used not only as a "flag" for
introducing lambda-expressions, but also is a macro which generates
functions. There is at least one precedent for having two
operations that do the identical thing -- NOT and NULL. Both have
been retained because they express different intents. In this case,
the intent of #'xxx might be to ``access'' a function by name (the
name of an anoymous function being its lambda expression), and the
intent of (LAMBDA ...) is to ``create'' a function. This distinction
is subtle but may be expressionally interesting to some programmers
in some situations.
Notationally, some people believe strongly that (LAMBDA ...) looks
a lot better than #'(LAMBDA ...). Certainly it takes up fewer
characters, and (LAMBDA ...) is a notable offender in code needing
to be split onto multiple lines, so every little bit probably helps.
Discussion:
Numerous people have suggested this from time to time in the past,
but it's often been amidst a bunch of other more controversial issues.
Pitman wrote up this proposal and supports LAMBDA-FORM:NEW-MACRO.
Technically, CLtL does already permit implementations to predefine a
LAMBDA macro, but most argue that this leeway was accidental. CLtL
says that "all" functions, etc in CLtL must be in the LISP package,
but it does not say "all and only". This oversight leaves enough room
for implementors to add all manner of extra junk in the LISP package.
A separate cleanup item (LISP-SYMBOL-REDEFINITION) addresses
this issue.
An earlier revision of this proposal considered the alternative of
making this a new special form. Many people prefered that alternative.
However, there were also strong objections to requiring a new special form;
since the FUNCTION special form is still necessary (for #'symbol),
it was deemed better to have LAMBDA a macro which is defined
in terms of FUNCTION than to have both LAMBDA and FUNCTION
as special forms.
∂08-Dec-88 1716 X3J13-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 17:16:11 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 16:58:45 PST
Date: 8 Dec 88 16:42 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-165845-4914@Xerox>
!
Forum: Cleanup
Issue: LISP-SYMBOL-REDEFINITION
References: Cleanup issue PACKAGE-CLUTTER
CLtL pp 67-69 Defining named functions
Category: CLARIFICATION
Edit history: Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
Masinter, Version 2, 7-Oct-88
Masinter, Version 3, 7-Oct-88, fix typos
van Roggen, Version 4, 13-Oct-88, undefined, not unspecified
Masinter, Version 5, 22-Nov-88, add more cases
Problem description:
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Proposal LISP-SYMBOL-REDEFINITION:DISALLOW
This proposal uses the phrase "the consequences are undefined" in the
sense that implementations may signal an error, or other undefined behavior
may ensue, and attempts to specify that user programs generally cannot
portably modify the behavior of the symbols in the LISP package.
For example, programming environments may warn the user about
redefinition of LISP symbols and then allow them. Some environments may
distinguish between functions that are safe to redefine and those that are
not.
Specify that the consequences of performing any of the following
operations are undefined:
* redefining as a function or macro any of the functions,
macros, or special forms defined in the LISP package;
* lexically defining (with FLET, LABELS or
MACROLET) any function or macro in the LISP package;
* attempting to rebind any symbol in CL defined as a constant;
this covers binding as with LET or LAMBDA, assignment
as with SETQ or SETF, or using MAKUNBOUND;
(implied by CLtL p. 69)
* defining type-specifiers as with DEFTYPE, DEFSTRUCT, or
DEFCLASS, any of the built in type specifiers, classes;
* defining or redefining SETF macros or functions of any
of the functions, macros or special forms that have specified
SETF behavior, using either DEFSETF or DEFINE-SETF-METHOD
(or with DEFUN if the proposal under SETF-FUNCTION-VS-MACRO
is adopted);
* applying TRACE to any function in the LISP package.
No other restrictions are placed on users attaching definitions
on symbols in the LISP package; for example, a user program
may
(DEFVAR CAR 3)
Examples:
The behavior of the construct:
(FLET ((OPEN (filename &key direction) (format t "Open called....")
(OPEN filename :direction direction)))
(with-open-file (x "frob" :direction ':output)
(format t "was Open called?")))
is undefined; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
(DEFUN CAR (X) (CDR X))
might signal an error.
Rationale:
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
Allowing arbitrary redefinition of symbols in the LISP package would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other LISP symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
Current practice:
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
Cost to Implementors:
This proposal clarifies the status quo -- that the consequences are undefined. It
allows and encourages implementors to check for such redefinition, but does not
require it.
Cost to Users:
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
Benefits:
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp.
Cost of non-adoption:
Continued questions.
Esthetics:
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble.
Discussion:
There have been various proposals for allowing users to extend the "protection"
mechanism to their own macros, functions, packages. These proposals seem like
they are environment issues and not language ones, however.
It is unfortunate that the restriction on reusing LISP package symbols in
FLET, LABELS or MACROLET is necessary, but the research into straightening out
the syntactic environment of macroexpansion isn't mature enough to put into
a standard yet.
∂08-Dec-88 1739 X3J13-mailer Issue: NTH-VALUE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 17:39:03 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 17:20:41 PST
Date: 8 Dec 88 17:15 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: NTH-VALUE (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-172041-4997@Xerox>
!
Issue: NTH-VALUE
References: Multiple values, pp. 133-139
Category: ADDITION
Edit history: 16-Aug-88, Version 1 by Pierson
01-Oct-88, Version 2 by Pitman (minor edits)
5-Oct-88, Version 3 by Masinter
(add Current Practice as per Gray)
8-Dec-88, Version 4 by Masinter
(add comments to discussion)
Problem description:
The set of operations on multiple values in Common Lisp is incomplete:
The only ways to retrieve just one of several return values (other than
the first) are:
- Bind several variables and then ignore all but one.
eg, (MULTIPLE-VALUE-BIND (X Y Z) <exp> (DECLARE (IGNORE X Y)) Z)
This is somewhat cumbersome to write and not perspicuous.
- Get a list of all return values and select from that.
eg, (THIRD (MULTIPLE-VALUE-LIST <exp>))
This is somewhat cumbersome, not perspicuous, and creates
needless garbage.
Proposal (NTH-VALUE:ADD):
Add a new macro NTH-VALUE, described as
NTH-VALUE n form [Macro]
Evaluates the FORM and returns the Nth value returned by the form as
a single value. N is 0-based, i.e. the first returned value is
value 0 (for consistency with NTH and NTHCDR). Both N and FORM are
evaluated, in left-to-right order.
Examples:
With this proposal MOD could be defined as:
(DEFUN MOD (NUMBER DIVISOR)
(NTH-VALUE 1 (FLOOR NUMBER DIVISOR)))
The same code would currently be:
(DEFUN MOD (NUMBER DIVISOR)
(MULTIPLE-VALUE-BIND (DIVIDEND REMAINDER)
(FLOOR NUMBER DIVISOR)
(DECLARE (IGNORE DIVIDEND))
REMAINDER))
Rationale:
This corrects the stated problem.
Current practice:
The TI Explorer and LMI Lambda have this feature.
Cost to Implementors:
Writing the macro version is fairly straightforward.
Some will choose to implement compiler hooks so that code written with
NTH-VALUE will be as efficient as possible. This may involve some
additional work, but presumably nothing major.
Cost to Users:
This is an upward-compatible change.
Cost of non-Adoption:
The occassional code where this comes up may be one or more of
clumsier to write, more difficult to read, or less efficient.
(The feature is rarely used in implementations that have it.)
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
While it does add another function to the language it removes
some need for the hairier multiple-value forms.
Discussion:
Pitman proposed this in the very late pre-CLtL days. It was
rejected then because it was too late in the cycle.
There was not strong sentiment for including this feature
in Common Lisp, but no active opposition.
Comments at the October 1988 X3J13 meeting:
"Trivial, gratuitous."
"Not trivial -- allows index computation. Hard to do this
in a portable, efficient way."
"Says he has an NTH-VALUE macro for a portable system that he
uses (which exploits the computed index feature) and that it's
a gross kludge in one implementation to make it efficient."
∂08-Dec-88 2041 X3J13-mailer Issue: PACKAGE-DELETION (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 20:41:45 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 20:40:59 PST
Date: 8 Dec 88 20:40 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: PACKAGE-DELETION (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-204059-5304@Xerox>
!
Forum: Cleanup
Issue: PACKAGE-DELETION
References: Packages (pp171-192), PACKAGE-NAME (p184), PACKAGEP (p76)
Category: ADDITION
Edit history: 30-Sep-88, Version 1 by Pitman
01-Oct-88, Version 2 by Pitman
04-Oct-88, Version 3 by Pitman
(provide for correctable errors in some cases)
07-Oct-88, Version 4 by JonL
21-Nov-88, Version 5 by Masinter
Problem Description:
There is no way to get rid of a package in Common Lisp.
This absence makes interactive development work tricky in some
implementations. If a package is accidentally built incorrectly, the
user must either rename the package to another package or start over
by reloading his program in a fresh lisp image.
Some programs need to create and destroy packages at runtime.
Without such a facility, some clumsy combination of RENAME-PACKAGE,
UNINTERN, and UNUSE-PACKAGE is usually made to work. However, it is
easy for a casual programmer to forget to undo some of the
bookkeeping, leading to unwanted effects.
Proposal (PACKAGE-DELETION:NEW-FUNCTION):
Introduce the function DELETE-PACKAGE, described as follows:
DELETE-PACKAGE package [Function]
Deletes PACKAGE from all package system data structures. PACKAGE may
be either a package or the name of a package.
If PACKAGE is a package name (i.e., not type PACKAGE) which does not
currently name a package, a correctable error is signalled. If
continued, no deletion action is attempted. Instead, DELETE-PACKAGE
immediately returns NIL.
If PACKAGE is a package object (i.e., an object of type PACKAGE)
which has already been deleted, no error is signalled and no further
deletion action is attempted. Instead, DELETE-PACKAGE immediately
returns NIL.
If the designated package is used by other packages, a correctable
error is signalled. If continued, the effect of UNUSE-PACKAGE is
done to remove any dependencies, causing its external symbols to stop
being accessible to those packages. Once this is done, DELETE-PACKAGE
goes on to delete the package just as it would had there been no
packages that used it.
After this operation completes, the contents of the symbol-package
slot of any symbol homed in the deleted package is unspecified; for
those symbols not homed in that package, the contents remain unchanged.
Except for this, symbols in the deleted package are not modified in
any other way.
The effect of DELETE-PACKAGE is that the name and
nicknames of the designated package cease to be recognized package
names. The package object is still a package -- PACKAGEP is true
of it -- but PACKAGE-NAME will return NIL. The effect of any other
package operation on PACKAGE once it has been deleted is undefined.
In particular, FIND-SYMBOL, INTERN and other functions that
look for a symbol name in a package will have unspecified results if
called with *PACKAGE* bound to the deleted package or with the
deleted package as an argument.
DELETE-PACKAGE returns T if the deletion attempt was successful
and NIL otherwise.
Examples:
(SETQ *FOO-PACKAGE* (MAKE-PACKAGE "FOO" :USE NIL))
(SETQ *FOO-SYMBOL* (INTERN "FOO" *FOO-PACKAGE*))
(EXPORT *FOO-SYMBOL* *FOO-PACKAGE*)
(SETQ *BAR-PACKAGE* (MAKE-PACKAGE "BAR" :USE '("FOO")))
(SETQ *BAR-SYMBOL* (INTERN "BAR" *BAR-PACKAGE*))
(EXPORT *FOO-SYMBOL* *BAR-PACKAGE*)
(EXPORT *BAR-SYMBOL* *BAR-PACKAGE*)
(SETQ *BAZ-PACKAGE* (MAKE-PACKAGE "BAZ" :USE '("BAR")))
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) => #<Package "BAR">
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) => "BAR:BAR"
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) => FOO:FOO, :EXTERNAL
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => FOO:FOO, :INHERITED
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => BAR:BAR, :INHERITED
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => "BAR"
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) => (#<Package FOO>)
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) => (#<Package BAZ>)
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
(DELETE-PACKAGE *BAR-PACKAGE*)
Error: Package BAZ uses package BAR.
If continued, BAZ will be made to unuse-package BAR,
and then BAR will be deleted.
Type :CONTINUE to continue.
Debug> :CONTINUE
=> T
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) is unspecified
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) is unspecified
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) is undefined
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => NIL, NIL
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => NIL, NIL
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => NIL
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
Rationale:
This facility corrects the deficiency described in the problem description.
Current Practice:
Symbolics has a function PKG-KILL which satisfies the proposed behavior
except that an error is not signalled if the package is used.
When a package is killed by PKG-KILL, the home package of all symbols
in that package are left undisturbed (i.e., local symbols pointing to
the killed package); this aspect is compatible with the stated proposal.
Procyon Common Lisp has a function called DELETE-PACKAGE already. It
returns the name of the package so deleted (as a string). [Perhaps it also
differs in the correctability of the errors it signals?]
Lucid Common Lisp implements DELETE-PACKAGE, except that the continuation
option for a name that doesn't name a package is different.
Cost to Implementors:
The cost of providing this facility is probably small.
Cost to Users:
Very slight to none. This change is essentially compatible.
Some code which cached packages in variables might have to be slightly
more cautious, but experience in the Symbolics implementation suggests
that it's really the responsibility of the person doing the DELETE-PACKAGE
to take care of worrying about the effects of having deleted the package:
normal programs need not bother testing a package for validity (using
PACKAGE-NAME) before using it.
Cost of Non-Adoption:
Getting rid of a package would continue to be difficult to do portably.
Benefits:
Better control of storage usage would be available portably.
Aesthetics:
No significant effect.
Discussion:
This was discussed as part of a larger bulk issue of how to undo all
sorts of definitions. Since that proposal has not gone anywhere
(perhaps bogged down under its own weight), this subtopic has been
broken off for separate discussion.
Note that if a symbol's package component is modified as a result
of being "unintern'd" from a delete packaged, then it is unspecified
as to how it will be printed.
∂09-Dec-88 0039 X3J13-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 00:39:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 00:38:45 PST
Date: 9 Dec 88 00:38 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 6)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-003845-5561@Xerox>
!
Issue: RETURN-VALUES-UNSPECIFIED
References: CLOSE (p 332), IN-PACKAGE (p 183), RENAME-PACKAGE (p 184),
TRACE (p 440), UNTRACE (p 440), INSPECT (p 442),
SET-SYNTAX-FROM-CHAR (p 361),
LOCALLY (p 156), PROVIDE (p 188), REQUIRE (P 188)
Related issues: REQUIRE-PATHNAME-DEFAULTS
CLOSED-STREAM-OPERATIONS
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
19-Sept-88, Version 2 by Chapman
6-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter
26-Nov-88, Version 5 by Masinter
9-Dec-88, Version 6 by Masinter
Problem Description:
The descriptions of CLOSE, IN-PACKAGE, RENAME-PACKAGE, TRACE, UNTRACE,
INSPECT, SET-SYNTAX-FROM-CHAR, LOCALLY, PROVIDE, and REQUIRE
are not clear about the values returned from those constructs.
Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
Clarify that the return values for the listed constructs are as follows:
CLOSE -- T
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the
execution of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
TRACE (when called with arguments) -- implementation-dependent.
UNTRACE -- implementation-dependent.
INSPECT -- implementation-dependent.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
surrounded by an implicit PROGN.
PROVIDE -- implementation-dependent.
REQUIRE -- implementation-dependent.
(NB: the issue CLOSED-STREAM-OPERATIONS proposes modifying
the return value of CLOSE on closed streams. The issue
REQUIRE-PATHNAME-DEFAULTS proposes removing
REQUIRE and PROVIDE. Those proposals would take
priority over this one.)
Rationale:
This clarification allows users to know when they can and can not
count on the values returned from these constructs.
Current Practice:
Varies; the choices made here are consistent with many but
not all implementations.
Cost to Implementors:
Small.
Benefits:
This clarification will assist users in writing portable code.
Cost to users:
Small; it seems unlikely that there is much code that currently
depends on the return values of these functions; such code isn't
portable.
Aesthetics:
Specified is better than not, when it makes sense.
Discussion:
PROVIDE and REQUIRE are not likely to appear except in the "top level" of
files, and so their return value is possibly moot. Another proposal would
eliminate them from the language, and then their return value would definitely
be moot!
There is some sentiment for leaving unspecified the values of the
debugging/environment features such as TRACE and UNTRACE,
for the same reasons that so much else of their behavior is unspecified.
Notes from Oct 88 X3J13:
Except for LOCALLY, why bother?
That just causes portability problems. Don't want to leave it
unspecified -unless- someone can cite a reason to do so.
"If many weren't defined, maybe we should leave 'em, but
since nearly all -are- defined, let's just go ahead and
round out the set."
Most text books she's seen show CLOSE returning NIL.
One text book shows it returning T.
Since some people like to think of T as success and NIL
as failure, maybe it should always return T.
(See Issue: CLOSED-STREAM-OPERATIONS.)
∂09-Dec-88 0057 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 00:57:39 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 00:56:50 PST
Date: 9 Dec 88 00:56 PST
From: masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <881209-005650-5575@Xerox>
This is a very difficult issue.
This writeup was distributed at the November 1987 meeting,
and at the October 1988 meeting.
There is another writeup, labelled Issue: SETF-PLACES which
will follow.
The following comments have not been incorporated into
this poposal:
Instead of generalizing SYMBOL-FUNCTION, add FDEFINITION and leave
SYMBOL-FUNCTION alone.
Do not modify TRACE and UNTRACE. Leave them implementation-dependent.
!
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
Version 3, 4-Nov-87 Moon, small clarifications at KMP's urging
PROBLEM DESCRIPTION:
The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand. It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.
PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS):
Add to Common Lisp the concept of "setf functions". Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function. The name of this setf function
is a list (setf -name-), where -name- is a symbol. The body of this
function is surrounded by an implicit block named -name-.
The functions, macros, special forms, and declarations defined in CLtL
and listed in the References section above need to be enhanced to accept
such lists in addition to symbols as function names, so that setf
functions can be defined and manipulated.
A setf function receives the new value to be stored as its first
argument. Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function, as for any function, is retrieved by
(documentation '(setf foo) 'function).
Examples:
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(funcall #'(setf ,(car form))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a similar feature,
in that they allow setting functions named (SETF reader). We don't
know of any implementation that has precisely the proposed feature.
ADOPTION COST:
The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols. Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.
The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.
This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.
COST OF NON-ADOPTION:
Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System. Some major rethinking of CLOS would be
required.
BENEFITS:
Allow CLOS to be defined without out-of-hand complexity.
Improve usability of SETF.
CONVERSION COST:
None, this is an upward-compatible change.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new
feature, but otherwise they will still work.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
DISCUSSION:
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. This proposal does not attempt to
change that.
There was some concern about introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
However, the CLOS unsuccessfully tried a number of alternatives.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
This proposal is not incompatible with other extensions to function
specifications present in some implementations.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
d) Introduce a new name for SYMBOL-FUNCTION, since it accepts
non-symbols now.
e) Should one allow these extended function names in the car-position
of an expression to be evaluated? The extra complexity didn't seem
justified, instead, an explicit FUNCALL is required.
----- End Forwarded Messages -----
∂09-Dec-88 0119 X3J13-mailer Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 01:19:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 01:13:30 PST
Date: 9 Dec 88 01:13 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
In-reply-to: masinter.pa's message of 9 Dec 88 00:56 PST
To: x3J13@Sail.Stanford.EDU
Message-ID: <881209-011330-5598@Xerox>
At the last meeting, our notes are that an amendment was offered and accepted:
" Remove SYMBOL-FUNCTION, TRACE and UNTRACE from the list of affected
functions.
Add a new function:
FDEFINITION <spec> [Function]
The current global function definition named by <spec> is returned.
It is an error if the <spec> has no function definition.
<spec> must be either a symbol or a list of the form (SETF <symbol>).
FDEFINITION may be used with SETF to alter the global function
definition.
"
This amendment was not been incorporated into Version 3.
∂09-Dec-88 0059 X3J13-mailer Issue: SETF-PLACES (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 00:59:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 00:58:47 PST
Date: 9 Dec 88 00:58 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: SETF-PLACES (Version 1)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-005847-5576@Xerox>
The following is the emmendation of SETF-FUNCTION-VS-MACRO that was
discussed at the Fairfax meeting; it incorporates the suggestions
made there by Gregor, Bob Kerns, and myself. Eric Benson and Patrick
Dussud here at Lucid have also reviewed it.
I've started it out under a different issue name, since it is such
a drastic change; but I wouldn't object at all if someone wants it
to be just another version of SETF-FUNCTION-VS-MACRO.
-- JonL --
!
Issue: SETF-PLACES
References: SETF rules for what a place-specifier can be; CLtL pp.94-7
X3J13 88-002R:
Accessing Slots, Ch. 1 p.11
DEFGENERIC Ch. 2 pp.26-9
DEFMETHOD Ch. 2 pp.39-41
(SETF DOCUMENTATION) Ch. 2 pp.43-5
ENSURE-GENERIC-FUNCTION Ch. 2 pp.46-7
GENERIC-FLET Ch. 2 p.52
GENERIC-LABELS Ch. 2 p.55-6
WITH-ADDED-METHODS Ch. 2 pp.90-1
Related issues: SETF-FUNCTION-VS-MACRO
Category: ADDITION
Edit history: Version 1, 11-Nov-88, by JonL
Problem description:
Common Lisp explicitly refrains from giving names to accessor update
functions. The intent is that the macro SETF should shield the user
from ever having to know such names; the correlation between an accessor
name and its corresponding updator name, or updating code sequence, is
to be established by DEFSETF and DEFINE-SETF-METHOD. Update function
names like SET and RPLACA are retained primarily for backwards
compatibility. See CLtL p.93-4.
However, this is extremely inconvenient for CLOS programing. The rub
is that the functionality of an updator function must be specifiable
"in pieces", by incremental uses of DEFMETHOD distributed throughout
perhaps dozens of files. A single definition using either DEFSETF or
DEFINE-SETF-METHOD is not an acceptable constraint for this style.
A named, generic function is the CLOS interface for doing distributed
code specification.
Furthermore, it is not at all clear where a DEFSETF call for a generic
function should go. Should it be before the first DEFMETHOD on the
update function? should it be bundled into every such DEFMETHOD?
should it be bundled into ENSURE-GENERIC-FUNCTION? Clearly, the first
two options would violate the modularity CLOS has strived so hard to
achieve; and the third violates the optionality of ENSURE-GENERIC-FUNCTION.
The best choice would be to elide the DEFSETF call completely. Some
way is needed to designate an update function, without necessarily
doing a DEFSETF or DEFINE-SETF-METHOD first.
Additionally the simpler form of DEFSETF, which could be used for
almost all generic needs (e.g., slot updating), requires the new-
value argument to be the last argument to the update function.
But in order to be able to discriminate upon the class of the
new-value argument, it cannot be described simply as "last" --
it must come before any &optional and &key arguments. Thus there
is need for some other avenue whereby the new-value argument would
come, say, first in the argument list of the update function.
Finally, the CLOS specification X3J13 88-002R seems to imply
that the CLOS exterior syntax for function specifiers must be
implemented down in the innards of every conforming Lisp
implementation. There is a very large amount of resistance
in the X3J13 group, at present, to any proposal which requires
any non-symbols as ordinary function names; not only do people
object to code like (SYMBOL-FUNCTION '(SOME LIST)), but there
is great reluctance to carry out system-wide modifications to
all places that deal with function names (most of which now
presume that "name" means SYMBOL). Yet is the current opinion
of most of the CLOS subcommittee that the exterior CLOS interface
can be kept intact without requiring the underlying Lisp
implementation to support non-symbols as function names.
Proposal (SETF-PLACES:ADD-SETF-FUNCTIONS)
-- Specify that certain function names are reserved to be "SETF functions",
or "updator functions", for use by SETF expansions. The very existence
of such an updator function is implicitly similar to having done a
DEFSETF [or rather, a modified form of the simple DEFSETF, as explained
next below]. Every accessor function name is uniquely paired with such
an updator name, regardless of whether the updator name ever has a
functional definition. However, these functions do not replace any
previously defined SETF methods, nor override the place specifications
of CLtL section 7.2; they simply provide a default expansion for SETF,
as described below.
-- Specify that such a a SETF function must take one more argument than
its corresponding access function. Let <access-fn> and <update-fn>
be such a correlated pair; then when SETF is given a "place" that is
a call on <access-fn>, it expands into a call on <update-fn> that is
given all the arguments to <access-fn> and also, as its very first
argument, the new-value (which must be returned by <update-fn> as
its value). For example, suppose that ASET is the updator function
name corresponding to AREF. Then
(SETF (AREF a i1 i2 ... in) value)
could expand into
(ASET value a i1 i2 ... in)
-- Extend the set of valid "place specifiers" as defined on CLtL p.94-7
by adding the following clause after all the existing ones:
For any other place specifier, the form
(SETF (<access-fn> A1 A2 ... AN) NEW-VALUE)
will expand into a call to the uniquely-named updator function
corresponding to <access-fn>, that is to the function named by
(UNDERLYING-NAME '(SETF <access-fn>)).
Note that SETF will no longer signal any "unknown place specifier"
errors during macroexpansion, because the default behavior is to
simply construct a call to the setf function [except, however, when
"access-fn" isn't legal as the name of a function; for example,
(setf ((spaz) i1 i2) value) is still syntaticly illegal]. But if
at run time, the "setf function" still hasn't been defined as a
function [such as by DEFUN, DEFMETHOD, setf of SYMBOL-FUNCTION etc.],
then a run-time "undefined function" error may occur.
Note also that not every SETF method for an accessor function can be
defined using an updator function. For example, LDB cannot be handled
this way, even if its corresponding update name is a defined function;
LDB must be handled by DEFINE-SETF-METHOD, and as such the prior rules
of CLtL p.94-7 would apply.
-- Be reminded that the rules for interpreting SETF place specifiers
are actually embodied in the functions GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than in the SETF macro
itself. Thus these two functions must be altered to reflect the new
"place specifier" called for just above. Since the rules on p.94-7
of CLtL are to be applied in order, then SETF functions will only be
used when no SETF "method" has been defined for the name, such as by
calling DEFINE-SETF-METHOD or DEFSETF; also, a macro definition for
the access name will block the use of the SETF function, since the
macro call must be expanded first. Remember also that such a updator
name may have a lexically local definition, as well as (or in addition
to) a global one.
-- Add a new function, UNDERLYING-NAME of one argument; and also add an
inverse for this function, UNDERLYING-NAME-TO-SPEC of one argument.
UNDERLYING-NAME is defined as:
(i) on any list like (SETF <name>), it returns a unique,
implementation-dependent name suitable for actual use as
a function name in that implementaion.
(ii) on symbols, it is the identity function; and
(iii) on any other data, it is undefined; however, other lists
like (<spec-kind> ...) should be reserved for extensions
which the x3J13 committee may be considering.
UNDERLYING-NAME-TO-SPEC is defined as:
(i) on any argument which specifically is the output of part (i)
above [i.e., an "underlying" name], it returns (SETF <name>);
thus the argument is the unique name which is EQUAL to
(UNDERLYING-NAME '(SETF <name>)).
(ii) on any symbol or list not covered by part (i) just above, it
returns it's argument.
(iii) on any other data, it is undefined; however, other lists
like (<spec-kind> ...) should be reserved for extensions
which the x3J13 committee may be considering.
The reason EQUAL is the determiner of "uniqueness" above is that it
is EQ for symbols; and for implementations which have "function specs"
it permits non-EQ copies of (SETF <name>) to be used interchangably.
The result of UNDERLYING-NAME should be constant across "incarnations"
of the same release of an implementation, and should be of a data type
that can be printed out and read back in reliably.
Thus in one implementation, which uses only symbols to name functions,
it might be that:
(UNDERLYING-NAME '(SETF FOO)) ==> SETF:4.USER.FOO
(UNDERLYING-NAME-TO-SPEC 'SETF:4.USER.FOO) ==> (SETF FOO)
whereas in another implementation, which has LispMachine style
"function specs", it would be that:
(UNDERLYING-NAME '(SETF FOO)) ==> (SETF FOO)
(UNDERLYING-NAME-TO-SPEC '(SETF FOO)) ==> (SETF FOO)
-- Alter all the above-referenced documentation in the CLOS specification
so as not to imply that lists are suitable as function names. In
particular,
(a) phrases like "... if <function-specifier> names a function" should
be changed to a phrase like "... if <function-specifier> refers to
a defined function", or possibly even something like
"... if (UNDERLYING-NAME <function-specifier>) names a function"
(b) phrases like "(FBOUNDP <function-specifier>)" should be changed
into "(FBOUNDP (UNDERLYING-NAME <function-specifier>))"; or
else other terminology should express the intent of what is to
be said. For example, instead of saying: "When (FBOUNDP <f-s>)
is true ..." one could just as well say "When <f-s> refers to
a defined function ..." The choice of which of these two formats
to use is an editorial one.
(c) phrases like "(SYMBOL-FUNCTION function-specifier)" should be changed
into "(SYMBOL-FUNCTION (UNDERLYING-NAME <function-specifier>))";
or else other terminology should express the intent of what is to
be said. For example, one might say "... the function referred
to by <f-s>". The choice of which of these two formats to use is
an editorial one.
Since the concept of a standard expansion for DEFMETHOD has been
accepted, then it is clear that a form like
(DEFMETHOD (SETF FOO) ...)
will expand exactly the same as
(DEFMETHOD #.(UNDERLYING-NAME '(SETF FOO)) ...)
The underlying call to ADD-METHOD will see the real function name used
for the updator function. The user-level interface of CLOS can still
present the list format as acceptable; it is only the implementation of
DEFMETHOD, DEFGENERIC, that will have to worry about converting to a
"real" name.
One expected use of UNDERLYING-NAME-TO-SPEC is in Lisp-level debuggers,
which could try to print out something more user-comprehensible than
the very internal names that an implementation might use in place of
function specs.
Examples:
;;; If CLtL did not already prescribe a SETF expansion for SUBSEQ calls,
;;; it could be defined like this:
(setf (symbol-function (underlying-name '(setf subseq)))
#'(lambda (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value i)))))
or, for implementations that have "function specs", this could be writen:
(defun (setf subseq) (new-value sequence start &optional end)
. . .)
;;; Here's an example using a local function. First, define
;;; MIDDLE-REF to be an accessor function as follows. [Assume
;;; also that MIDDLE-REF's home package is BAR.]
(defun middle-ref (vec i)
(check-type i fixnum)
(aref vec (ceiling i 2)))
;;; Now let SETF:3.BAR.MIDDLE-REF be the (implementation-dependent)
;;; updator function name corresponding to MIDDLE-REF; a normal
;;; definition of an update function for MIDDLE-REF could be:
(defun setf:3.bar.middle-ref (new-element vec i)
(check-type i fixnum)
(setf (aref vec (ceiling i 2)) new-element))
;;; But the SETF below will call FILL, because of the local definition
;;; of SETF:3.BAR.MIDDLE-REF; and nowhere have we have made any
;;; explicit call to DEFSETF or DEFINE-SETF-METHOD for MIDDLE-REF.
(flet ((setf:3.bar.middle-ref (new-element vec i)
;;"wide-body" version of set-middle-ref
(declare (ignore i))
(fill vec new-element :end (ceiling i 2))))
(setf (middle-ref "abc" 1) #\z))
;;; The following function could be called by GET-SETF-METHOD, to
;;; implement SETF functions, when none of the other rules of CLtL
;;; p.94-7 apply.
(defun get-setf-method-for-setf-functions (form)
(let* ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v)))
((access-fn (car form)))
((update-fn (underlying-name `(SETF ,access-fn)))))
(values temp-vars
(cdr form)
(list new-value)
`(,update-fn ,new-value ,@temp-vars)
`(,access-fn ,@temp-vars))))
;;; For those implementations using "function specs", the form:
;;; `(,update-fn ,new-value ,@temp-vars)
;;; would probably have to be replaced by:
;;; `(FUNCALL #',update-fn ,new-value ,@temp-vars)
Rationale:
The paragraphs of the "Problem description:", except for the first,
describe four major problems with the status quo -- three concerning
the unsuitability of current SETF methods for supporting the CLOS
generic style, and one for an unintended presumption that every
implementation of CL will have "function specs". This proposal
corrects these problems, without adding any significant new ones.
Current practice:
Some implementations have "function specs", so that forms like
(SETF FOO) are permitted to name functions; but none have extended
the setf place specifiers as proposed herein.
Cost to Implementors:
Basically, none. Implementations which already have Lisp Machine
style "function specs" can just define UNDERLYING-NAME and
UNDERLYING-NAME-TO-SPEC as the identity function. For those without
such capabilities, there is a portable implementation listed in the
discussion section.
Extending GET-SETF-METHOD etc. to handle SETF functions should be a
very modest task at most.
Cost to Users:
This is basically an upward-compatible addition, so there should be
no cost to users [at least not for correct programs -- incorrect
SETF expansions will no longer be signalled at macroexpand time,
but may simply result in a runtime error for undefined function.]
Cost of non-adoption:
Non-adoption of this proposal would be a significant setback for the
Common Lisp Object System. There seems to be no agreeable alternative
for implementing generic setf methods.
Performance impact:
N.A.
Benefits:
See "Cost of non-adoption".
Esthetics:
This proposal increases the size of the definition of SETF; but
it greatly simplifies the "default" case, namely just defining
an updator function to correspond to an accessor.
Discussion:
The following code can be used by an implementation which doesn't
have "function specs" to implement the new functions:
;;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: SYSTEM; Base: 10 -*-
;;;
;;; Author: JonL White, 15-Nov-88
;;;
(in-package "SYSTEM") ;or, your development package
(eval-when (eval compile load)
;;; The SETF package should be reserved for this purpose
;;;
(or (find-package "SETF")
(make-package "SETF" :use nil))
(defparameter *setf-package* (find-package "SETF"))
(unless (and (null (package-use-list *setf-package*))
(null (package-used-by-list *setf-package*)))
(error "SETF package has connections?"))
;;; "Internal Markers", to be used for uninterned symbols.
;;;
(export (intern "SETF-SPEC" *setf-package*) *setf-package*)
(export (intern "SETF-NAME" *setf-package*) *setf-package*)
)
(eval-when (eval compile)
(defmacro setf-spec-p (x)
(let ((spec (gensym)))
`(LET ((,spec ,x))
(AND (CONSP ,spec)
(EQ (CAR ,spec) 'SETF)
(CONSP (CDR ,spec))
(NULL (CDDR ,spec))
(SYMBOLP (SECOND ,spec))))))
)
(defun UNDERLYING-NAME (spec)
(cond
((symbolp spec)
spec)
((setf-spec-p spec)
(let* ((accessor (second spec))
(accessor-name (symbol-name accessor))
(home-package (symbol-package accessor)))
(if home-package
(let* ((package-name (package-name home-package))
;; 'spec-name' is a form like "~D.~A.~A", but FORMAT has a
;; problem with global print parameters like *print-radix*
(spec-name (concatenate 'string
(write-to-string (length package-name)
:radix nil :base 10 :length nil :level nil)
"."
package-name
"."
accessor-name))
(updator (or (find-symbol spec-name *setf-package*)
(let ((sym (intern spec-name *setf-package*)))
(export sym *setf-package*)
sym))))
;; A possible optimization, which trades off space for time, is
;; as follows; see definition of UNDERLYING-NAME-TO-SPEC below
;;(setf (get updator 'setf:setf-spec) (copy-list spec))
updator)
(or (get accessor 'setf:setf-name)
(let* ((uname (concatenate 'string "SET-" accessor-name))
(updator (make-symbol uname)))
(setf (get accessor 'setf:setf-name) updator)
(setf (get updator 'setf:setf-spec) (copy-list spec))
updator)))))
(t
(error "~S is an invalid arg for ~S" spec 'UNDERLYING-NAME))))
(defun UNDERLYING-NAME-TO-SPEC (x)
(cond
((not (symbolp x))
(if (setf-spec-p x)
x
(error "~S is an invalid arg for ~S"
x 'UNDERLYING-NAME-TO-SPEC)))
((get x 'setf:setf-spec))
(t
(let ((home-package (symbol-package x)))
(if (not (eq home-package *setf-package*))
x
(let ((name (symbol-name x))
accessor package-name)
;; Unpack the name, which is a form like "~D.~A.~A"
(multiple-value-bind (nchars starti)
(parse-integer name :radix 10 :junk-allowed t)
(incf starti)
(setq package-name (subseq name starti (incf starti nchars)))
(incf starti)
(setq accessor (find-symbol (subseq name starti)
(find-package package-name)))
(unless accessor
(error "~S failed to parse in ~S"
x 'UNDERLYING-NAME-TO-SPEC))
`(SETF ,accessor))))))))
----- End Forwarded Messages -----
∂09-Dec-88 0119 X3J13-mailer Issue: FUNCTION-DEFINITION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 01:19:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 01:11:17 PST
Date: 9 Dec 88 01:10 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FUNCTION-DEFINITION (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-011117-5596@Xerox>
!
Issue: FUNCTION-DEFINITION
References: Issue FUNCTION-TYPE
Category: ADDITION
Edit history: 23-Jun-88, Version 1 by Pitman
09-Dec-88, Version 2 by GZ (change name, remove REQUIRED
option, specify first value to be a lambda, add to
discussion and current practice)
Problem Description:
There are portable ways to turn symbols and lists into functions,
but there are no portable ways to get back the original symbols and
lists given the functions.
In many cases, it used to be possible to recover the lambda expression
after a DEFUN by using FUNCTION or SYMBOL-FUNCTION, but the passage of
FUNCTION-TYPE will make this no longer be the case.
Proposal (FUNCTION-DEFINITION:FUNCTION-SOURCE):
Introduce a new function called FUNCTION-SOURCE which takes as
its argument a function and returns three values:
#1: The function's defining lambda expression, or NIL if the information
is not available. The lambda expression may have been pre-processed
in some ways, but it should remain a suitable argument to COMPILE
or FUNCTION.
#2: NIL if the definition was enclosed in the null lexical
environment or something non-NIL if the definition might
have been enclosed in some non-null lexical environment.
#3: the `name' of this function. The name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations are free to always return NIL T NIL, but are encouraged
to return the lambda expression in the case where the argument was created
by an in-core call to COMPILE or EVAL (as opposed to being created by
loading a compiled file).
Examples:
The following examples illustrate some possible return values, but
are not intended to be exhaustive:
#1: (FUNCTION-SOURCE #'(LAMBDA (X) X))
or (FUNCTION-SOURCE (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
#2: (FUNCTION-SOURCE (FUNCALL #'(LAMBDA (X) #'(LAMBDA () X)) NIL))
might return NIL, T, NIL
or (LAMBDA () X), T, NIL
but -not- (LAMBDA () X), NIL, NIL
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION 'BAR) #'FOO)
(FUNCTION-SOURCE #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) (BLOCK FOO X)), T, NIL
or (LAMBDA (X) (BLOCK FOO X)), NIL, FOO
or (SI::BLOCK-LAMBDA FOO (X) X), NIL, FOO
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-SOURCE (FOO))
might return NIL, T, NIL
or (LAMBDA (X) (BLOCK BAR X)), T, NIL
or (LAMBDA (X) (BLOCK BAR X)), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) (BLOCK BAR X)), NIL, "BAR in FOO"
Rationale:
This functionality would be useful to a pretty printer, debugger,
inspector, and other tools.
Cost to Implementors:
The following implementation is technically legitimate, although many
implementations would want to provide something more useful:
(DEFUN FUNCTION-SOURCE (FUNCTION)
(CHECK-TYPE FUNCTION FUNCTION)
(VALUES NIL T NIL))
Current Practice:
Many implementations record this information, but not all that do
publish an interface to extracting the information. VAXLISP and
Lucid call it SOURCE-CODE. Coral calls it UNCOMPILE-FUNCTION.
The language T has this operation and calls it DISCLOSE. It is the
conceptual inverse of the ENCLOSE which occurs in some Scheme dialects,
and is implemented as what CLOS would call a "generic function".
Cost to Users:
None. The change is upward compatible.
Cost of Non-Adoption:
Certain kinds of portable debugging tools would be harder to write.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
The phrase ``program is data; data is program'' comes up a lot in discussions
about Lisp. This makes the case for ``program is data'' more interesting.
Discussion:
The initial name proposed for this function was FUNCTION-DEFINITION. This
was changed because of technical uses of the term ``definition'' to refer
to the entire defining form (e.g. a DEFUN form) rather than the lambda
expression that might be recovered from it.
The possibility of _requiring_ the lambda expression to be available for
all functions created by in-core calls to COMPILE or FUNCTION was considered
but didn't receive much support. Pitman would prefer that option because
it is considerably more useful in practice, but would like to see at least
the current proposal.
∂09-Dec-88 0133 X3J13-mailer Issue: STREAM-ACCESS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 01:32:55 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 01:31:00 PST
Date: 9 Dec 88 01:30 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: STREAM-ACCESS (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-013100-5620@Xerox>
!
Issue: STREAM-ACCESS
References: streams (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 17-Jun-88, version 1 by Walter van Roggen
30-Nov-88, version 2 by Masinter
Problem Description:
There are many components of streams which are specified upon creation
but are not accessible afterwards. Furthermore there is no way in
Common Lisp to determine the type of a stream to see if it has particular
components, or even if it is OPEN.
The accessors wanted are those associated with broadcast streams,
concatenated streams, echo streams, file streams, string streams,
synonym streams, two way streams.
There are three proposals, which differ only by the whether
they include types, type predicates, or both, in addition to
the stream component acessors. Ballots can be either for
one of the proposals or none. (Other combinations of, say,
accessors without either predicates or types, or types without
accessors, do not seem reasonable and are not being proposed
at this time.)
Proposal STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
First, add a function to determine whether a stream is "OPEN":
OPEN-STREAM-P stream [Function]
Returns T if a stream is open, NIL if it is closed. It is an error
if the argument is not a stream.
Streams are "open" until they have been closed with
CLOSE, or, the dynamic context of the creating/accessing
macros of WITH-OUTPUT-TO-STRING, WITH-OPEN-FILE,
WITH-INPUT-FROM-STRING, WITH-OPEN-STREAM,
have been exited.
There are three kinds of things to add associated with each kind of
stream: data types, predicates, accessors.
Stream data types:
BROADCAST-STREAM (returned by MAKE-BROADCAST-STREAM)
CONCATENATED-STREAM (returned by MAKE-CONCATENATED-STREAM)
ECHO-STREAM (returned by MAKE-ECHO-STREAM)
FILE-STREAM (returned by OPEN or created by WITH-OPEN-FILE)
STRING-STREAM (returned by MAKE-STRING-INPUT-STREAM,
MAKE-STRING-OUTPUT-STREAM, and created by WITH-INPUT-FROM-STRING
and WITH-OUTPUT-TO-STRING and FORMAT with second argument NIL)
SYNONYM-STREAM (created by MAKE-SYNONYM-STREAM)
TWO-WAY-STREAM (created by MAKE-TWO-WAY-STREAM)
The stream data types are all subtypes of type STREAM and are mutually
exclusive. (In particular, a synonym stream is only of type SYNONYM-STREAM.)
Stream Predicates:
Each of these returns T if the object is of the corresponding type,
and NIL otherwise.
BROADCAST-STREAM-P, CONCATENATED-STREAM-P,
ECHO-STREAM-P, FILE-STREAM-P, STRING-STREAM-P,
SYNONYM-STREAM-P, TWO-WAY-STREAM-P
Note that the predicates do not "follow the link" of a synonym
stream.
Stream Informational Functions:
BROADCAST-STREAM-STREAMS broadcast-stream ==> list of streams
This function returns a list of output streams that constitute
all the streams the broadcast stream is broadcasting to. It is
an error if the argument is not of type BROADCAST-STREAM.
CONCATENATED-STREAM-STREAMS concatenated-stream ==> list of streams
This function returns a list of input streams that constitute
the ordered set of streams the concatenated stream still has to
to read from, starting with the current one it is reading from.
The list may be () if no more streams remain to be read.
It is an error if the argument is not of type CONCATENATED-STREAM.
ECHO-STREAM-INPUT-STREAM echo-stream ==> input-stream
ECHO-STREAM-OUTPUT-STREAM echo-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type ECHO-STREAM.
SYNONYM-STREAM-SYMBOL synonym-stream ==> symbol
This function returns the symbol whose SYMBOL-VALUE the
synonym stream is using. It is
an error if the argument is not of type SYNONYM-STREAM.
TWO-WAY-STREAM-INPUT-STREAM two-way-stream ==> input-stream
TWO-WAY-STREAM-OUTPUT-STREAM two-way-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type TWO-WAY-STREAM.
Proposal: STREAM-ACCESS:ADD-TYPES-ACCESSORS
Identical to ADD-TYPES-PREDICATES-ACCESSORS except to leave out the
stream type predicates.
Proposal: STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
Identical to ADD-TYPES-PREDICATES-ACCESSORS except to not
identify new data types. The accessors act as if the types were specified
(i.e., are mutually excusive).
Current Practice:
VAX LISP implements ADD-TYPES-PREDICATES-ACCESSORS.
We have not surveyed other implementations.
Cost to Implementors:
All of the proposals are reasonably simple to implement, since the information
must be present for nearly all types.
Cost to Users:
The proposals are upward-compatible, and should have little impact.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
Discussion:
This issue has come up frequently, particularly dealing with SYNONYM-STREAMs.
The behavior of OPEN-STREAM-P on, for example, broadcast streams, might
be specified in a variety of alternative ways. This specification seems the simplest.
There are three proposals for voting because there was no agreement at the
October X3J13 on the issue of whether types, predicates, or both should be
added.
There was a proposal at one time to add a new function FOLLOW-SYNONYM-STREAM
which could be written as
(defun follow-synonym-stream (x)
(if (synonym-stream-p x)
(follow-synonym-stream (symbol-value (synonym-stream-symbol x)))
x))
i.e., which chases through zero or more synonym stream indirections.
∂09-Dec-88 1008 X3J13-mailer Issue: STREAM-INFO (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 10:07:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 10:03:19 PST
Date: 9 Dec 88 10:02 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: STREAM-INFO (Version 6)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-100319-6354@Xerox>
An amendment to this proposal is under consideration, to change
the following names:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
("PRINTED-WIDTH is misleadingly named (in my opinion) because the function PRINT
is not involved. STREAM-WRITTEN-WIDTH looks a little weird.)
!
Forum: Cleanup
Issue: STREAM-INFO
References: FORMAT ~T (pp398-9) and ~<...~> (pp404-6), PPRINT (p383)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman (2d model)
23-Jun-88, Version 2 by Waters (1d model, modified 2d model)
24-Jun-88, Version 3 by Pitman (minor reformatting)
24-Jun-88, Version 4 by Pitman (remove 2d model for submission)
23-Sep-88, Version 5 by Waters (cleaned up in response to
discussion)
30-Nov-88, Version 6 by Masinter (add discussion)
Problem Description:
Currently, there is no portable way to inquire about the line width of
an output stream, the current position on a line, or the amount of
space that the display of a string will take up. This makes it
essentially impossible to write a portable implementation of a pretty
printer.
Proposal STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS:
Introduce four new functions.
These functions are carefully designed with an eye to the way they
interact. As a result, they can only be defined fully in terms of
each other. The presentation below first gives a very brief
definition of each function and then gives detailed specifications of
their relationships.
LINE-WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a number representing the line width available
when printing to OUTPUT-STREAM. If the stream has no meaningful
width (or the width cannot be computed) then NIL is returned.
LINE-POSITION &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a number representing the current horizontal
position on the current output line, or NIL if the position cannot
be computed.
WRITE-SPACE WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [function]
Inserts blank space of length WIDTH into OUTPUT-STREAM. WIDTH must
be a non-negative number. WRITE-SPACE returns T if the operation
is successful and NIL otherwise (e.g., if the operation is not
supported by OUTPUT-STREAM).
PRINTED-WIDTH STRING &optional (OUTPUT-STREAM *STANDARD-OUTPUT*)
&key (START 0) (END NIL) [Function]
Returns a number representing the horizontal width that would be
required to display STRING if it were written at the current moment
to OUTPUT-STREAM using (WRITE-STRING STRING OUTPUT-STREAM :start
START :end END), or NIL if this width cannot be computed. The width
may be negative (e.g., if STRING contains backspace or newline
characters.)
PRINTED-WIDTH does not return any indication of the vertical
distance required when printing STRING. The START and END
parameters delimit a substring of STRING in the usual manner.
PRINTED-WIDTH never causes any change in the state of OUTPUT-STREAM.
The width returned may well depend on the current state of
OUTPUT-STREAM (e.g., the width of tabs depends on the line position
and the width of characters depends on the font in use.) In all
respects the width is computed based on the current state of the
stream. However, the width returned always assumes that the total
line width is infinite---i.e., does not reflect any wraparound or
truncation which might occur.
-The difficulties of a full specification:
The functions above are intended to solve a specific current problem
in CL. To serve this purpose, they must have reasonably precise
specifications. However, there are several things which make it
desirable to have specifications which allow for significant
variability between implementations. First, current implementations
of CL differ greatly in the way IO is supported, and overly strict
specifications might make things very difficult for certain
implementations. Second, CL places no limits on the kinds of
idiosyncratic characters which can be supported by particular
implementations. Third, while many CL implementations only support
the printing of characters in fixed width fonts, it is desirable to
allow for output streams that support variable width fonts.
Finally, it is desirable to leave room to move for the future.
-Operations on standard characters where the line-width has not yet been
exceeded.
To deal with the problems above, a layered specification is
provided. The lowest level specification is given in terms of
constraints between the four functions above. In this lowest level
specification, two key simplifying assumptions are made. First, it
is assumed that at the time the constraint applies, none of the
previous operations on the stream S in question have caused output
to go beyond the physical horizontal limits of the output device on
the output lines relevant to the constraints. I.e., it is assumed
that truncation and or wraparound of the output has not occurred on
these lines. Second, it is assumed that all of the characters
output to the stream on the output lines relevant to the constraints
are standard characters as defined in CLTL pp 20-21. The
non-standard character #\newline may have been used to end one line
and start the next. (Note that standard characters are all simple
characters such as A-Z. Particularly, #\tab, #\backspace,
#\newline, are NOT standard characters.) It is further assumed that
the strings (X and Y) referred to in the constraints consist solely
of standard characters.
Basic properties of LINE-POSITION:
1- For all S, (not (minusp (line-position S)).
2- For all S, (zerop (line-position (progn (terpri S) S))).
3- For all S, If something is at line position N on one line and
something else is at line position N on another line, then the
two things are lined up vertically one under the other.
Defining property of WRITE-SPACE
4- For all N,S, let M = (+ (line-position S) N)
if M <= (line-width S), then
(= (line-position (progn (write-space N S) S)) M)
Defining property of PRINTED-WIDTH
5- For all X,S, let M = (+ (line-position S) (printed-width X))
if 0 <= M <= (line-width S), then
(= (line-position (progn (write-string X S) S)) M)
Basic property of LINE-WIDTH
6- For all N,S, let P = (line-position S)
If (+ P N) <= (line-width S) then
(write-space N S) is guaranteed to output space on the end of
the current line without any truncation of wraparound occurring.
7- For all X,S, let P = (line-position S)
If 0 <= (+ P (printed-width X)) <= (line-width S) then
(write-string X S) is guaranteed to output X on the end of
the current line without any truncation of wraparound occurring.
Additional properties of PRINTED-WIDTH
8- For all X,Y (= (printed-width (concatenate 'string X Y) S)
(+ (printed-width X S) (printed-width Y S)))
9- For all X,Z (= (printed-width X S)
(progn (write-string Z S) (printed-width X S)))
-Support for varying width fonts.
A key motivation behind the functions above is dealing with
arbitrary kinds of output devices and output streams that support
variable width fonts. To provide for this, the properties above
place no absolute constraints on the units used for the width
values. In fact, the units can vary from stream to stream. The
only thing that is required is that for a given stream, the units
must be a constant throughout the life of the stream, and the four
functions above must all operate in terms of the same units. The
units should be chosen to be small enough to represent the minimum
possible difference in the length of two strings and large enough
that it is possible to perform (write-space 1). (I.e., a single
pixel is a logical choice.)
If an output stream only supports a single fixed width font, then
the logical width unit to choose is the width of a single character.
Given this choice, the following is a minimal implementation of the
four functions that meets the requirements above.
LINE-WIDTH returns the maximum number of characters which can be
printed on a single line. LINE-POSITION returns the number of
characters output since the last #\newline (or since the creation of
the stream if no #\newlines have been output). (WRITE-SPACE N S)
outputs N #\space characters. Finally, (PRINTED-LENGTH X S) =
(length X).
-Support for non-standard characters and situations where line width
has been exceeded.
In the main, the properties above can be supported even if the line
width has been exceeded and even when non-standard charactres are
involved. However, characters such as #\tab and #\newline can make
it impossible to support properties 7 and 8. In addition, when the
line width is exceeded, property 3 may not hold. It is hoped that
implementors will make a good faith effort to support the functions
in the full range of situations which can be encountered in their CL
implementations. However, the simple implementation suggested above
will probably provide at least 80% of the benefits intended. As a
result, it is important that people not allow the potential
difficulties of a full implementation deter them from making a
minimal implementation.
-Support for derivative streams.
Intentionally, very little is said about what the width units should
be or exactly what LINE-WIDTH should return. The only key criterion
is that LINE-WIDTH should return a result that is pessimistic enough
to ensure proper printing. However, it is useful to make some
comments about these matters with regard to certain types of
derivative streams.
If a synonym stream, two way stream, or echo stream is created, it
should have the same line-width and width unit as the base output
stream.
A string output stream should have a line-width of NIL and probably
should be treated as supporting a fixed width font and having an
output width unit so that each character has a printed-width of 1.
If a broadcast stream is created, then LINE-LENGTH, LINE-POSITION,
and PRINTED-WIDTH should be be supported by reflecting them through
to the FIRST base stream. (There is no guarantee that anything
reasonable can be done with the streams as a set. For example, one
might support a varying length font while the others don't.) An
attempt should be made to send WRITE-SPACE requests to all of the
base streams. However, they may not come out right on other than
the first base stream.
Test Case:
Suppose that S is an output stream that supports a single fixed
width font which can display 72 characters on a line and that the
associated width unit is the width of one character. Evaluating the
following will produce the results shown.
(line-width S) => 72
(terpri S) => nil
(output-position S) => 0
(printed-width "testing: " S) => 9
(write-string "testing: " S) => "testing: "
(line-position S) => 9
(write-string "foo" S) => "foo"
(terpri S) => nil
(write-space 9 S) => T
(write-string "bar" S) => "bar"
The output produced is
testing: foo
bar
Rationale:
Pretty printing requires the function LINE-WIDTH to know how wide the
output it produces can be. Pretty printing requires LINE-POSITION to
determine where on the line output is when pretty printing starts.
Pretty printing requires PRINTED-WIDTH to determine how much space
things will take in the output. (If a variable width font is being
used, this cannot be determined without a detailed knowledge of the
font being used.) (Properties 7 & 8 greatly reduce the number of
times PRINTED-WIDTH has to be called.) Pretty printing requires
WRITE-SPACE to get proper indentations. (If a variable width font is
being used, indentations may be required that cannot be obtained by
outputting spaces.)
Current Practice:
Essentially every implementation of Common Lisp must support the
minimal functionality above internally in order to support PPRINT and
the FORMAT directives ~T and ~<...~>. However, there is no documented
interface to this functionality in CLTL. As a result, while some
implementations of Common Lisp make this functionality available to
users, some do not. Further, the implementations that do provide
this functionality do so in a variety of incompatible ways.
Cost to Implementors:
This proposal is written in such a way as to allow implementations
which do not have the ability to compute difficult values to just
return NIL. Very little work is forced. The idea is to offer
implementors a common way to provide this useful information to
portable programs where possible.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Complex output programs such as pretty printers cannot be written
portably.
Benefits:
A wide range of programs can gain better control of the format of output.
Aesthetics:
No significant aesthetic impact other than a slight increase in the
number of functions defined.
Discussion:
This issue probably should have been called PRETTY-PRINT-WIDTH-SUPPORT.
Dick Waters (author of GPRINT, a portable pretty printer), originally
raised this issue.
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is the minimum required to support
pretty printing into a stream which displays output using a variable width
font.
Originally the functions were defined to return integers; however, there
are some output devices (e.g., those that have arbitrary scaling
operations), for which it would be difficult to find a reasonable
least-common-denominator for line-width.
We considered an alternate proposal which goes significantly beyond what is
needed merely for pretty printing and provides primitives
LINE-DIMENSIONS, LINE-POSITION, PRINTED-DIMENSIONS, and WRITE-SPACE but
it is not included here. A key point of contention was the question of how
to handle the issue of vertical distance (where is the origin, which way
do you count, ...).
We considered requiring PRINTED-WIDTH to return two additional values:
the number of newlines that WRITE-STRING of the string would execute and
the maximum X position encountered (which might differ from the first value
if the number of newlines was non-zero).
This feature wasn't strictly necessary for pretty-printing, and so was
omitted.
Some of the draft proposals from the character committee contained some
proposed functions that were attempting to solve the same problem.
Conflicting proposals should be avoided.
∂09-Dec-88 1047 X3J13-mailer Issue: SYMBOL-MACROLET-DECLARE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 10:47:13 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 10:32:48 PST
Date: 9 Dec 88 10:32 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: SYMBOL-MACROLET-DECLARE (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-103248-6444@Xerox>
!
Issue: SYMBOL-MACROLET-DECLARE
References: SYMBOL-MACROLET (88-002R page 2-81)
WITH-ACCESSORS (88-002R page 2-88)
WITH-SLOTS (88-002R page 2-92)
Related Issues: SYMBOL-MACROLET-SEMANTICS
FLET-DECLARATIONS (passed)
Category: ADDITION
Edit history: Version 1, 12-Sep-88, Moon
Version 2, 9-Dec-88, Masinter
(add cross reference, discussion)
Problem description:
It would be both natural and nice to be able to write
(with-slots (rho theta) point
(declare (single-float rho theta))
...computation...)
Proposal (SYMBOL-MACROLET-DECLARE:ALLOW):
Allow declarations at the head of the body of SYMBOL-MACROLET, and hence
in WITH-ACCESSORS and WITH-SLOTS. Exactly the same declarations are
allowed as for LET, with one exception: SYMBOL-MACROLET signals an error
if a SPECIAL declaration names one of the symbols being defined as a
symbol-macrolet. A type declaration of one of these symbols is equivalent
to wrapping a THE expression around the expansion of that symbol.
Example:
See problem description.
Rationale:
If SYMBOL-MACROLET is intended to resemble LET in syntax, it ought to
allow declarations. When writing a SYMBOL-MACROLET directly, the user
could just as easily write a THE expression instead of a type
declaration. However, when invoking a macro such as WITH-SLOTS that
expands into SYMBOL-MACROLET, the user does not have this option since
the expansion is not supplied explicitly by the user.
Current practice:
SYMBOL-MACROLET was only tentatively added to Common Lisp 3 months ago.
Cost to Implementors:
Less than one man-hour.
Cost to Users:
None.
Cost of non-adoption:
Minor wart in the language.
Benefits:
More consistent language definition.
Esthetics:
More consistent language definition.
Discussion:
This issue is related to SYMBOL-MACROLET-SEMANTICS.
"A macro-definition for SYMBOL-MACROLET would leave the issue of
DECLARE open. But the special-form version of SYMBOL-MACROLET
really should address it."
∂09-Dec-88 1047 X3J13-mailer Issue: SYMBOL-MACROLET-SEMANTICS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 10:47:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 10:40:52 PST
Date: 9 Dec 88 10:40 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: SYMBOL-MACROLET-SEMANTICS (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-104052-6470@Xerox>
!
Issue: SYMBOL-MACROLET-SEMANTICS
References: SYMBOL-MACROLET (88-002R page 2-81)
Related Issues: SYMBOL-MACROLET-DECLARE
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
22-September-88, Version 3 by Piazza
22-September-88, Version 4 by Piazza
30-Nov-88, Version 5 by Masinter
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion in the same lexical environment as the
symbol macro invocation, exactly analogous to normal macros. Clarify that
within the body of a SYMBOL-MACROLET, SETQ of a symbol defined as
a symbol macro will be treated as if it were a SETF.
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Current Practice:
Portable CommonLoops (PCL) provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Rather than extending the existing MACROEXPAND and MACROEXPAND-1
functions, new functions could be introduced to expand symbol macros.
However, there seems to be no particular reason to do this.
∂09-Dec-88 1407 X3J13-mailer Caveat on "From: cl-cleanup..."
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 14:06:52 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 DEC 88 13:52:02 PST
Date: 9 Dec 88 13:50 PST
From: masinter.pa@Xerox.COM
Subject: Caveat on "From: cl-cleanup..."
To: X3J13@sail.stanford.edu
Message-ID: <881209-135203-1007@Xerox>
While many of the issues distributed for your consideration have been
considered at length, a significant percentage have had last-minute changes
with little or no review by other cleanup committee members.
The urgency of getting items ready for voting coupled with the vacation and
work schedules of cleanup committee members has caused more haste than
usual.
∂09-Dec-88 1406 X3J13-mailer Issue: TAGBODY-CONTENTS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 14:06:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 13:39:52 PST
Date: 9 Dec 88 13:39 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TAGBODY-CONTENTS (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-133952-701@Xerox>
!
Forum: Cleanup
Issue: TAGBODY-CONTENTS
References: TAGBODY (pp 130-131 of CLtL)
Category: CLARIFICATION
Edit History: 13-Sep-88, version 1 by Walter van Roggen
02-Oct-88, version 2 by Pitman
(beef up rationale, clarify tag NIL is ok)
04-Oct-88, version 3 by Pitman (fix wording bug)
05-Oct-88, version 4 by Pitman
(modify proposal based on comments from Peck@Sun
-- allow both (GO NIL) and unused duplicated tags)
9-Dec-88, Version 5 by Masinter (wording per Pitman)
Problem Description:
CLtL specifies that symbols and integers are valid tags
in a TAGBODY and that lists are valid forms in a TAGBODY
but is silent about other data types.
Also, NIL is both a symbol and a list. Some implementations
might permit (GO NIL) because they treat NIL as a tag,
while others might not permit because they treat NIL as a form.
Proposal (TAGBODY-CONTENTS:FORBID-EXTENSION):
A TAGBODY's body may contain arbitrary data elements; no
constraints are placed on duplication of those elements.
duplications. Elements that are lists (CONSP) are evaluated in
left-to-right order. Any other elements are ignored by TAGBODY. However,
GO is only legal when the given a tag that is a symbol or integer. The results
of executing GO when there is more than one instance of the same (EQL)
tag at the top level of the innermost TAGBODY containing that tag are
unspecified.
In particular it is an error to use a character, floating point number,
ratio or other data element as a tag to GO.
The same restrictions apply to all forms which implicitly use
TAGBODY, such as PROG and DO.
Examples:
;; legal, but useless
(TAGBODY 3.4 4.5 (print "hi there"))
;; not legal
(tagbody
(ecase char (#\a (go #\a)) (#\b (go #\b)))
#\a (print "Apple")
#\b (print "Ball"))
;;legal, even when args are NIL:
(defmacro foo1 (&rest args)
`(do () ((test-fn))
,(when (member :bar args) '(do-bar-thing))
,(when (member :baz args) '(do-baz-things))
(do-regular-things)))
;; legal, but bad style
(do (...)
(...)
-----
(...)
(...)
-----
(...))
Rationale:
The proposed set of tags is expressionally adequate.
Other candidate types have lurking problems that could
lead to subtle program bugs if permitted as tags. For example,
- Characters make bad tags because, for example,
(TAGBODY ... #\Return ... #\Newline ...)
will be an error in some implementations due to
(EQL #\Return #\Newline).
- Floats make bad tags because round-off error will vary
between implementations.
- Rationals have problems with reduction to lowest terms.
eg, (EQL 1/2 2/4). This doesn't vary between implementations
but may still cause surprises.
Duplicated tags are permitted in situations where no GO is done
to them; it is not our intent particularly to encourage the
practice. . But current practice is to permit such uses in
many implementations, and there was no driving
reason to force such code to break.
Current Practice:
Symbolics Genera documents that only symbols or integers are permitted.
The restriction is enforced by the compiler, but not the interpreter.
The TI Explorer permits using NIL as a GO tag, but as a special case,
does not warn about multiple appearances of NIL.
Many implementations allow duplicate tags if there is no GO to them.
Cost to Implementors:
A few simple checks are probably all that's needed. Probably most
implementations (both interpreters and compilers) already perform them.
Implementations that disallow duplicate tags (generally in the
compiler but not the interpreter) will have to remove the
error checks.
Cost to Users:
Unlikely to affect any portable code.
If there are implementations which support other objects as tags
(floats, for example), other (likely minor) changes will be
necessary.
Benefits:
One less place for portability problems to occur.
Aesthetics:
Makes the language description more precise.
Discussion:
This issue was first included in in ">GLS>clarifications.text"
of 12/06/85.
Historical Note (JonL, Steele):
The reason pdp10 MacLisp allowed numbers, including flonums,
as tags was that Ira Goldstein's LLOGO (a LOGO system
written entirely in Lisp) just used READ for the statement
numbers, and they looked like floats; e.g., 1.1, 1.2, ... etc.
∂09-Dec-88 1531 X3J13-mailer Issue: TEST-NOT-IF-NOT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 15:31:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 15:30:26 PST
Date: 9 Dec 88 15:26 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TEST-NOT-IF-NOT (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-153026-1243@Xerox>
This issue has two proposals.
Some people have indicated that they will vote for
one of these only conditionally, e.g.,
"Yes, if you change "REMOVE" to "DEPRECATE" and define the
term "DEPRECATE" in a way that permits the retention of these
primitives for the near term with intent to phase them out
later."
!
Forum: Cleanup
Issue: TEST-NOT-IF-NOT
References: Functions offering a :TEST-NOT keyword:
ADJOIN (p276), ASSOC (p280), COUNT (p257), DELETE (p254),
DELETE-DUPLICATES (p254), FIND (p257),
INTERSECTION (p277), MEMBER (p275), MISMATCH (p257),
NINTERSECTION (p277), NSET-DIFFERENCE (p278),
NSET-EXCLUSIVE-OR (p278), NSUBLIS (p275), NSUBST (p274),
NSUBSTITUTE (p256), NUNION (p276), POSITION (p257),
RASSOC (p281), REMOVE (p253), REMOVE-DUPLICATES (p254),
SEARCH (p258), SET-DIFFERENCE (p278),
SET-EXCLUSIVE-OR (p278), SUBLIS (p274), SUBSETP (p279),
SUBST (p273), SUBSTITUTE (p255), TREE-EQUAL (p264),
UNION (p276);
Functions with "-IF-NOT" in their name:
ASSOC-IF-NOT (p280), COUNT-IF-NOT (p257),
DELETE-IF-NOT (p254), FIND-IF-NOT (p257),
MEMBER-IF-NOT (p275), NSUBST-IF-NOT (p274),
NSUBSTITUTE-IF-NOT (p256), POSITION-IF-NOT (p257),
RASSOC-IF-NOT (p281), REMOVE-IF-NOT (p253),
SUBST-IF-NOT (p273), SUBSTITUTE-IF-NOT (p255);
Related Issue: FUNCTION-COMPOSITION
Category: CHANGE
Edit history: 02-Oct-88, Version 1 by Pitman (just FLUSH-ALL)
05-Oct-88, Version 2 by Pitman (add option FLUSH-TEST-NOT)
Problem Description:
The -IF-NOT functions are functionally unnecessary.
The :TEST-NOT keywords are not only functionally unnecessary but
also problematic because it's not clear what to do when both :TEST
and :TEST-NOT are provided.
Many people think Common Lisp is more `bloated' than it needs
to be and these aspects of the language are commonly cited
specific examples.
Proposal (TEST-NOT-IF-NOT:FLUSH-ALL):
Remove all -IF-NOT functions (named above) from Common Lisp.
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler.
The removal of :TEST-NOT also makes the language easier to explain.
Cost to Implementors:
Very slight.
Some symbols would disappear from the LISP package but could
still be offered in proprietary packages if deemed important
enough.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Proposal (TEST-NOT-IF-NOT:FLUSH-TEST-NOT):
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler and easier to explain.
Cost to Implementors:
Very slight.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Current Practice:
Presumably no one has done this yet.
Cost to Users:
Some rewrites would be needed.
Those rewrites, which are already fairly simple, would be even
more simple if some form of the FUNCTION-COMPOSITION issue is
voted in -- in particular, the COMPLEMENT function which it
proposes would help enormously in this regard.
Cost of Non-Adoption:
Common Lisp would continue to be what some people feel is
"bigger than it needs to be".
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Presumably this makes the language easier to teach.
Performance impact:
Very small; removing the :TEST-NOT keywords would
make the simple implementation of the functions that
used to have them slightly faster, but the resulting
code of the inner loop is likely to be much slower.
Discussion:
Many people objected strongly to both of these proposals --
they might have been a nice idea five years ago, but are
gratuitous incompatibilities now: incompatible changes with
insufficient payback.
Some of those objections might be tempered if some additional
changes were made to Common Lisp: adding a COMPLEMENT
function, or if there were a strategy to declare some parts of the
language "obsolete". Since these conditions haven't been done,
their objections stand.
Steele noted that one main reservation to FLUSH-ALL is that
he uses REMOVE-IF-NOT much more than REMOVE-IF.
This issue is related to FUNCTION-COMPOSITION, but is not
dependent on it. Some support the combination of FLUSH-ALL and
the NEW-FUNCTIONS part of FUNCTION-COMPOSITION in spite of
the incompatible change because of the aesthetic appeal.
Some people expressed their intention to vote for FLUSH-ALL
only if FUNCTION-COMPOSITION:NEW-FUNCTIONS.
It was noted that and
adding a #~ readmacro such that
(FIND-IF-NOT #'ZEROP '(0 0 3))
== (FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
== (FIND-IF #~ZEROP '(0 0 3))
The modification of these functions is moot for those who
prefer to use extended LOOP macro/iteration constructs
in lieu of the sequence functions.
Several alternative names for REMOVE-IF-NOT were
suggested: KEEP-IF, ABSTRACT, FILTER. We did not
pursue these suggestions.
∂09-Dec-88 1605 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 16:05:10 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 15:58:54 PST
Date: 9 Dec 88 15:58 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-155854-1325@Xerox>
This issue arose during the discussion of issue
COERCE-INCOMPLETE, and was only recently cast as
a formal proposal in its own right.
!
Forum: Cleanup
Issue: TYPE-OF-UNDERCONSTRAINED
References: TYPE-OF (CLtL)
88-002R (Class-of)
88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
DATA-TYPE-HIERARCHY-UNDERSPECIFIED
FUNCTION-TYPE
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
COERCE-INCOMPLETE
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 1-Dec-88, Masinter
Version 2, 9-Dec-88, Masinter
Problem description:
The specification of TYPE-OF in CLtL is so weak as to leave it
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.
This means that implementations could return T for all other objects.
Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS):
Specify that the result of TYPE-OF satisfies the following:
(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of
INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER
SYMBOL,
STRING, VECTOR, ARRAY,
CONS,
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize.)
(b) For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)
(c) will be a MEMBER type specifier, or T.
For objects created by the "constructor" function of a structure
defined with DEFSTRUCT without a :TYPE option, TYPE-OF
will return the structure name.
For objects created by MAKE-INSTANCE, giving a named
class, TYPE-OF will return the class name of the class.
For objects which are instances of anonymous classes (i.e., where
(CLASS-NAME (CLASS-OF object)) is NIL), the result of TYPE-OF should be the
class object itself.
(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)
This proposal is intended to be consistent with 88-002R,
and not to conflict with any of the definitions in that document.
Examples:
It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
Given:
(defvar *foo* (make-array 5 :element-type t))
(class-name (class-of *foo*)) => SIMPLE-VECTOR
It is legal for
(type-of *foo*) => (SIMPLE-VECTOR 5)
Rationale:
The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended.
Current practice:
Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.
Cost to Implementors:
Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal.
Cost to Users:
Apparently none.
Cost of non-adoption:
TYPE-OF would remain potentially inconsistent.
Performance impact:
Likely none.
Benefits:
Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.
Esthetics:
Little effect.
Discussion:
Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.
The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did.
This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.
If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass,
and this proposal does pass, it may be that the only way an
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.
It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable
implementation-specific value. For example,
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]
We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.
∂09-Dec-88 1618 X3J13-mailer Issue: VARIABLE-LIST-ASYMMETRY (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 16:17:57 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 16:17:10 PST
Date: 9 Dec 88 16:16 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: VARIABLE-LIST-ASYMMETRY (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-161710-1373@Xerox>
!
Issue: VARIABLE-LIST-ASYMMETRY
References: CLtL pgs. 110, 122, 131
Category: ADDITION
Edit history: 26-Jul-88, Version 1 by Skona Brittain
04-Aug-88, Version 2 by Skona Brittain
08-Oct-88, Version 3 by Pitman
Problem Description:
The syntax of items in the variable-list for various control structues
(do, do*, let, let*, prog, prog*, and compiler-let) varies. This
variation seems unnecessary.
The allowed variations are indicated in the following chart:
do & do*: (var) (var init) (var init step)
prog & prog*: var (var) (var init) n.a.
let & let*: var (var val) n.a.
compiler-let var (var value)
Note that just plain `` var '' is prohibited in do forms
and that the case of ``(var)'' is prohibited in let forms
and compiler-let forms.
Proposal (VARIABLE-LIST-ASYMMETRY:SYMMETRIZE):
Allow all the variations in all of the forms;
i.e. add the prohibited cases mentioned above.
I.e. change the variable-list in the syntax descriptions as follows:
do & do*: ( { var | (var [init [step]] ) }* )
let & let*: ( { var | (var [value] ) }* )
compiler-let: ( { var | (var [value] ) }* )
Test Cases:
(let (a (b) (c 3)) ... ) would be valid.
(let* (a (b) (c 3)) ... ) would be valid.
(do (a (b) (c 3)) ... ) would be valid.
(do* (a (b) (c 3)) ... ) would be valid.
(compiler-let (a (b) (c 3)) ... ) would be valid.
Rationale:
The asymmetry is unnecessary and impedes learning of CL.
Any other way to make these cases consistent, such as either
omitting just ``var'' from do & do* and prog & prog*, or
omitting ``(var)'' from let & let* and prog & prog*,
would be an incompatible change to the language.
This way just adds the flexibility found in some of the forms to all of them.
Current Practice:
KCL allows ``(var)'' in let & let* but not ``var'' in do & do*.
Symbolics Genera allows all three cases in all the forms; i.e. it conforms
to this proposal.
Cost to Implementors:
Extremely slight. (May involve subtracting code rather than adding it).
Cost to Users:
None.
Cost of Non-Adoption:
The variation in syntax makes them harder to learn.
Benefits:
Ease of learning.
Aesthetics:
Symmetry is more aesthetic than asymmetry, at least to some of us.
Discussion:
Pitman supports this proposal.
The issue about whether the atomic ``var'' should be allowed at all in the
variable lists for let & let* is a separate issue. (So is whether
it should mean that the var is initially bound to nil.) Since it is allowed,
this proposal merely says that the alternative syntax of an atom within a
list with no initial value, ``(var)'', should also be allowed.
∂09-Dec-88 1705 X3J13-mailer Issue: DECLARATION-SCOPE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 17:05:11 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 17:00:53 PST
Date: 9 Dec 88 17:00 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: DECLARATION-SCOPE (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-170053-1466@Xerox>
This issue has two proposals, NO-HOISTING and LIMITED-HOISTING.
!
Issue: DECLARATION-SCOPE
References: Declaration Syntax (CLtL, Section 9.1, pp. 153-157)
LAMBDA-Expressions (CLtL, Section 5.2.2, pp. 59-66)
Cleanup issue FLET-DECLARATIONS (accepted)
Cleanup issue DECLARE-TYPE-FREE (accepted)
Category: CHANGE/CLARIFICATION
Edit history: V1: Hornig@Symbolics.COM -- 5 January 1988
Version 2, Moon, 2-Feb-1988 (edits based on discussion)
Version 3, Moon, 18-Sep-88, for private discussion between JonL and Moon
Version 4, JonL, 15-Nov-88 add 2nd proposal; major rewrite.
Problem description:
The description of the scope of declarations made with DECLARE is
unclear (although unambiguous) and arguably a mistake. At issue is
whether the scope of some or all of the declarations at the head of
a special form includes code appearing in any non-body part of that
special form. CLtL p.155 attempts to address the issue by classifying
declarations into two classes -- "pervasive" and "non-pervasive" -- but
it does not succeed very well.
A particular question of interest is whether the initial value forms for
LET, LET*, FLET, LABELS, DO, PROG etc. are included. The rules of CLtL,
on some cases, are clear enough to see that a declaration inside the
special form is "hoisted" up and around the whole form, so as to include
all the "initial value" forms (and "stepper" forms and "result" forms for
those constructs that have them). This means that lexical argument
variable X in the following function is inaccessible inside the initial
value forms of the LET:
(defun bar (x y) ;[1] 1st instance of x
(let ((old-x x) ;[2] 2nd instance of x -- same as 1st instance?
(x y)) ;[3] 3rd instance
(declare (special x))
(list old-x x)))
The declaration intended for the binding of X[3] also alters the
scoping of the reference of X[2]; likely, this was not an intended
consequence. [This is a simplification of the example on CLtL p.155].
In this discussion, the term "body" will include any "stepper" or
"result" forms, such as might be found in a DO or DO-mumble-SYMBOLS
construct. The reasoning for this is that such forms are always
included in the scope of all name bindings (if any) being established
by the special form. They form an extended part of the "body".
Proposal (DECLARATION-SCOPE:NO-HOISTING)
Specify that the scope of a declaration located at the head of a special
form or lambda expression is as follows:
(1) it always includes the body forms [as well as any "stepper" or
"result" forms]
(2) it also includes the scope of the name binding, if any, to which
it applies [LET, LAMBDA, FLET, DO, etc. introduce "name bindings";
LOCALLY doesn't.];
This very straightforward prescription depends on one rather subtle
point, namely that the scope of name bindings is an already solved
question. Whether or not a particular declaration affects an initial
value form (such as for LET or LET*) depends _solely_ on whether it is
applied to a variable or function (name) being bound whose scope
includes such forms. In this sense, the above specification limits the
scope of declarations for name bindings to be exactly the scope of the
name binding itself -- i.e. "like variable". Thus there would be no
"hoisting" of the special declarations in the example cited in the
problem description. [See the Discussion section for a review of the
CL rules on variable/function-name scoping in special forms.]
Those declarations not correlated with any name binding do not cover any
of the initial-value forms; their scope simply includes the body (as well
as any "stepper" or "result" forms). In a sense, the above specification
limits the scope of these kinds of declarations to be the same as an
arbitrary name binding in a LET or FLET construct -- i.e. "like variable".
[See also the issue DECLARE-TYPE-FREE.]
Thus there is to be no "hoisting" for declarations in special forms or
lambda expressions; the only initial value forms affected by a declaration
will be those included indirectly, by the effect, if any, that a
declaration has on a name binding.
A question may arise as to what it means for a declaration to "apply to",
or "be correlated to" a name binding. As stated above about variable
scoping, this is an already solved question in Common Lisp; it is not
the purpose of this proposal to alter, clarify or in any other way bear
upon the basic _applicability_ rules of declarations in Common Lisp.
However, a few reminders about these rules will help one understand the
above specification:
-- SPECIAL and TYPE declarations never apply to function bindings;
-- INLINE and FTYPE declarations never apply to variable bindings;
-- OPTIMIZE never applies to either kind of binding;
-- (<declaration> X) never applies to a binding of Y.
The specific rules are for the most part distributed throughout the
individual declaration definitions. The name-applicibility issue for
bindings must be specified independently of how the declaration scoping
issue is decided, and should not be confused with that scoping issue.
Proposal (DECLARATION-SCOPE:LIMITED-HOISTING)
Specify that the scope of a declaration located at the head of a special
form or lambda expression is as follows:
(1) it always includes the body forms [as well as any "stepper" or
"result" forms]
(2) if the declaration is applicable to a name binding in that form,
then it is limited to exactly the scope of that name binding [LET,
LAMBDA, FLET, etc. introduce "name bindings"; LOCALLY doesn't.];
(3) if the declaration is not applicable to a name binding in that form,
then it includes all the initial value forms, in addition to the
body forms.
This very straightforward prescription depends on one rather subtle
point, namely that the scope of name bindings is an already solved
question. This applies not only to LET and LET* variables, but to the
&optional, &key and &aux variables of LAMBDA-Expressions. In this sense,
the above specification limits the scope of declarations for name bindings
to be exactly the scope of the name binding itself. Thus there would be
no "hoisting" of the special declarations in the example cited in the
problem description.
Those declarations not correlated with any name binding act as if they
were included in a new LOCALLY construct wrapped around the entire
special form. Thus they are not scoped like an arbitrary variable
(or, "name binding") in that special form, but rather are "hoisted" up.
Whether or not a declaration is "hoisted" up around the special form in
which it occurs depends on whether or not it is "captured en passant" by
a correlated name binding.
A question may arise as to what it means for a declaration to "apply to",
or "be correlated to" a name binding. As stated above about variable
scoping, this is an already solved question in Common Lisp; it is not
the purpose of this proposal to alter, clarify or in any other way bear
upon the basic _applicability_ rules of declarations in Common Lisp.
However, a few reminders about these rules will help one understand the
above specification:
-- SPECIAL and TYPE declarations never apply to function bindings;
-- INLINE and FTYPE declarations never apply to variable bindings;
-- OPTIMIZE never applies to either kind of binding;
-- (<declaration> X) never applies to a binding of Y.
The specific rules are for the most part distributed throughout the
individual declaration definitions. The name-applicibility issue for
bindings must be specified independently of how the declaration scoping
issue is decided, and should not be confused with that scoping issue.
Examples:
;;; The following example is from a common-lisp mailing list discussion
;;; (from code suggested by Pavel Curtis). The question is whether or
;;; not the special declaration in FOO applies to the (1+ x) form.
(setf (symbol-value 'x) 6)
(defun foo (x) ;a lexical binding of X
(print x)
(let ((x (1+ x))) ;is the second X special or not?
(declare (special x)) ;`normal' declaration
(bar))
(1+ x))
(defun bar () (print (locally (declare (special x)) x)))
(foo 10) will printout of 10 and 11 by either proposal herein
(foo 10) will printout of 10 and 7 by CLtL style "hoisting"
;;; The following example is due to Jim Boyce, of Lucid Inc. It shows how
;;; the "hoisting" of the declaration inadvertently causes it to act more
;;; like a proclamation than a declaration; namely, the declaration is
;;; applied to two different variables (which happen to have the same
;;; name) -- the first variable is the lexical one bound on line [1] and
;;; the second variables is bound on line [3]. Whereas lexical scoping
;;; rules would say that the reference in line [2] is to the variable
;;; bound on line [1], the effect of the "hoisted" declaration is to
;;; make the line [1]'s variable inaccessible in the initial value forms.
(setf (symbol-value 'x) 6)
(defun bar (x y) ;[1] 1st instance of x
(let ((old-x x) ;[2] 2nd instance of x -- same as 1st instance?
(x y)) ;[3] 3rd instance
(declare (special x))
(list old-x x)))
(bar 'first 'second) ==> (first second) ;by either proposal herein
(bar 'first 'second) ==> (6 second) ;by "hoisting", a la CLtL.
Rationale:
These semantics are simpler to understand. Almost everyone feels that
the example of CLtL p.155 is very unnatural. LIMITED-HOISTING is less
of a change to CLtL semantics; but NO-HOISTING seems more natural to
most people since it restores a closer equivalence between LET forms
and LAMBDA-expressions. Also, several vendors report that customers
frequently seem to assume the semantics of NO-HOISTING.
Current practice:
Most implementations implement the rules in CLtL, as exemplified by
the example on p.155. Symbolics currently implements rules based on
Zetalisp which are different from both this proposal and Common Lisp.
Symbolics plans to change to Common Lisp rules in the future.
Cost to Implementors:
Modest; some minor fixes will be necessary to to compilers, interpreters
and "code walkers" that parse declarations.
Cost to Users:
Modest. It is mostly moot since users tend to avoid the "hoisting"
situations on special declarations.
It is possible to mechanically examine a program to determine whether
its behavior would change under the new rules. This permits an
implementation to provide a transition tool to ease conversion to the
new definition.
Cost of non-adoption:
Serious non-portability of code, since not every implementor seems to
agree on how to read the disputed rules of CLtL pp. 153-157; continuing
confusion in the user community.
Performance impact:
None.
Benefits:
Elimination of confusion; increase of portability between implementations.
Esthetics:
Simplifies the scoping issue; eliminates special-case scoping rules for
SPECIAL declarations.
Discussion:
Only the SPECIAL declaration has semantic import for CL; both
proposals specify an incompatible change for this case, to "retract"
the expansive scope stated or implied in CLtL. All other declarations
are considered "advice" to an optimizing compiler, and should have
no semantic effect on correct programs. However, programmers making
use of such declarations may notice a larger difference in the
NO-HOISTING proposal, since some of their INLINE, OPTIMIZE, TYPE,
etc. declarations will no longer apply to the initial-value forms.
One idiom which will be adversely affected by both of these proposals is:
(let ((*a* *a*))
;; rebind *a* to it's "old" value
(declare (special *a*))
...)
where *a* has not been proclaimed special. This idiom would likely
have to be written as:
(let ((*a* (locally (declare (special *a*)) *a*)))
;; rebind *a* to it's "old" value
(declare (special *a*))
...)
or [preferably!] *a* should be proclaimed special. Similar idiots
like this may be in use for LAMBDA-Expressions, or DEFUNs etc.
On the other hand, the inadvertent "shadowing" which prevents the
following LET's initial value forms from referencing the input argument
is handily solved by either proposal herein. If neither of these
proposals is not adopted, then the intent of the code for BAR:
(defun bar (x y) ;[1] 1st instance of x
(let ((old-x x) ;[2] 2nd instance of x -- same as 1st instance?
(x y)) ;[3] 3rd instance
(declare (special x))
(list old-x x)))
would likely have to be expressed by introducing new LET contours:
(defun bar (x y) ;[1] 1st instance of x
(let ((old-x x)) ;[2] 2nd instance of x -- same as 1st instance?
(let ((x y)) ;[3] 3rd instance
(declare (special x))
(list old-x x))))
The source of additional confusion has long been that TYPE declarations
had to be treated differently from all other declarations; this was because
of the prohibition found on p158 of CLtL. Given the acceptance of the
DECLARE-TYPE-FREE proposal, it no longer is necessary to make an exception
for it, nor to categorize declarations into "pervasive" and "non-pervasive",
or "free" and "bound".
It is not the purpose of this proposal to alter, clarify or in any
other way bear upon the scoping rules of variables in Common Lisp.
However, a few reminders about these rules will help one understand
the above prescription. Except LET*, PROG*, DO*, LABELS, and MACROLET,
all the other special forms of CLtL p154 which admit declarations have
the property that the scope of the name binding does not include any
initial value form. As a review of these scopes, note:
-- for LET, FLET, MULTIPLE-VALUE-BIND, none of the initial value
forms are included in the variables' (or functions') scope;
-- for DO-<mumble>-SYMBOLS, the initial value forms are not included,
but the optional result forms are included;
-- for DO, DOLIST, and DOTIMES, the initial value forms are not
included, but the stepper forms and the optional result forms
are included;
-- for LET*, PROG*, and DO*, a variable's scope also includes the
remaining initial value forms, for subsequent variable bindings;
-- for LABELS and MACROLET, a function name's scope includes all the
code forms for the functions being defined by the special form
[a compiler writer must know how not to get into an infinite loop
of substitutions when there are 'in-line' declarations on these
mutually recursive names];
-- for a LAMBDA application, none of the explicit value forms are
included in the bound variable scoping; however, the 'initform'
code (if any) for &optional, &key, and &aux bindings are included
in the same way as LET* does;
-- for DEFUN, DEFMACRO, DEFTYPE and DEFSETF follow the rules for
LAMBDA-Expressions (CLtL, Section 5.2.2, pp. 59-66).
Remember also that new name bindings "shadow" (after a fashion) any
higher level binding or declarations. E.g., presuming that no
proclamations are in effect, consider the inner let bindings of:
(locally (declare (special x) (float y))
(let ((x 5) (y 10))
(print (+ x y))))
then x is bound as local (not special); and y is bound with no particular
type information [because the 'y' being bound is a different variable
than the 'y' declared float in the outer scope].
It has been suggested that compilers could be a bit more helpful in
detecting anomalous bindings, such as in the LET* following:
(defun bar (x y)
(let* ((old-x x)
(x y)
(new-x x))
(declare (special x))
(list old-x x new-x)))
The collection of variables named X in the LET* binding and initial
forms includes both local (lexical) and special ones.
∂09-Dec-88 1742 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 17:41:49 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 17:35:03 PST
Date: 9 Dec 88 17:34 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: DECLARE-TYPE-FREE (Version 8)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-173503-1691@Xerox>
This is one of several variations discussed.
!
Forum: Cleanup
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Related issues: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
DECLARATION-SCOPE
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Version 5, 30-Sep-88, Masinter (cost to implementors)
Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
Version 7, 5-Dec-88, Masinter (scope->extent)
Version 8, 7-Dec-88, Masinter (back to scope)
Problem description:
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
any effect:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
(incf y)
...random algorithm...))
Proposal (DECLARE-TYPE-FREE:ALLOW):
Specify that a type declaration does not only "affect variable bindings";
rather, type declarations are legal in all declarations. The interpretation
of a type declaration is that, during the execution of any expression
within the scope of the declaration, it is an error for the value of
the declared variable not to be of the declared type. For declarations
that are associated with variable bindings, the type declaration also
applies to the initial binding of the variable. In the special case
of a declaration for which there are no executable expressions
within the scope of the declaration (e.g., (locally (declare (integer x)))),
the result is as if there were executable expressions.
Examples:
;; this is an error:
;; the assertion that x is a fixnum is violated between the two
;; calls to (zap)
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(zap)
x)))
;; this is an error, because the assertion that x is a fixnum
;; is violated during the call to zap, even though few
;; implementations will be able to check:
(let ((x 12) (y 'foo))
(flet ((zap ()
(rotatef x y)
(rotatef x y)))
(locally (declare (fixnum x))
(zap)
x)))
;; this is an error, even though the violation of the type
;; constraint happens after the form with the declaration
;; is exited.
(let ((f (let ((x 3)) (declare (fixnum x)) #'(lambda (z) (incf x z)))))
(funcall f 4.3))
Rationale:
This proposal enables optimizing compilers to make use of the otherwise
ignored type information. Many people have often asked for it, and
there is no strong reason to forbid it.
Current practice:
Lucid Common Lisp allows "free" type declarations; under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
Implementations that might currently warn about such declarations
would have to remove the warning; otherwise, it is valid to ignore
type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
every reference.
Esthetics:
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
language.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
Documentation might want to discuss the style implications of
nested declarations intersecting. The interesting cases are:
- An inner declaration could be a subtype of an outer one.
This is the most useful case and probably the only one to
be encouraged in code written by humans. e.g.,
(locally (declare (type number x))
(locally (declare (type integer x))
...use X as integer...))
- An outer declaration could be a subtype of an inner one.
This is useless but harmless. It might happen as the result
of certain macro situations. e.g.,
(locally (declare (type integer x))
(locally (declare (type number x))
...use X as integer...))
- Two types may only partially overlap. This would presumably
happen only as the result of a macro expansion.
(locally (declare (type fixnum x))
(locally (declare (type (or bit package) x))
...use X as BIT...))
∂10-Dec-88 0348 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Dec 88 03:48:01 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03444g; Sat, 10 Dec 88 03:45:20 PST
Received: by bhopal id AA00267g; Sat, 10 Dec 88 03:47:17 PST
Date: Sat, 10 Dec 88 03:47:17 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812101147.AA00267@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 9 Dec 88 15:58 PST <881209-155854-1325@Xerox>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
I believe this issue was incorrectly mailed to X3J13. By "cleanup" rules,
only those issues that have "settled down in sub-committee" are to be
mailed out now, and this issue has been under daily disucssion for the
past week. Furthermore, this version 2 has had no review whatsoever;
worse yet, it appears to have an egregious bug in it (a logical inversion
in one sentence).
-- JonL --
∂10-Dec-88 0513 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Dec 88 05:13:53 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03592g; Sat, 10 Dec 88 05:11:16 PST
Received: by bhopal id AA00374g; Sat, 10 Dec 88 05:13:13 PST
Date: Sat, 10 Dec 88 05:13:13 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812101313.AA00374@bhopal>
To: masinter.pa@Xerox.COM
Cc: x3j13@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 9 Dec 88 17:34 PST <881209-173503-1691@Xerox>
Subject: Issue: DECLARE-TYPE-FREE (Version 8)
Please retract this Issue from X3j13 now. You (Larry) substantially
reworked it during the past few days, and provided no opportunity for
review by the principals who originated the proposal.
In particular, if I read Kent's commentary right, from the msg:
Date: Wed, 19 Oct 88 15:42 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 6)
then his intent, along with that of Moon and myself (who also worked
on this proposal), is diametrically opposite of what you now have it
to be.
In particular, your explanation:
;; this is an error:
;; the assertion that x is a fixnum is violated between the two
;; calls to (zap)
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(zap)
x)))
was explained as exactly the opposite by Kent on 19-Oct-88; and the rest
of us have always agreed that "free" type declarations need not be
consistent with "specialized storage" -- that they are merely equivalent
to wrapping (THE <type> ...) around lexical occurances of the variable.
It this point is debateable, it should have been debated in subcommittee
before "release" of the issue.
-- JonL --
∂10-Dec-88 1236 X3J13-mailer ISO Meeting Status
To: ROSENKING@a.ISI.EDU
CC: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
As I mentioned in my trip report, the January ISO meeting which was to
have been held immediately following the X3J13 meeting has been cancelled.
There is no possibility to revive it now. Also as I mentioned, I believe
that the meeting was hastily cancelled - had I been chairman of the
committee I would not have suggested the cancellation and I would not have
entertained the motion to cancel unless there was an overwheling sense of
the committee that it should be cancelled, regardless of any personal
circumstances such as lack of travel funds.
All of the US ISO representatives will, I believe, be at the January X3J13
meeting, and it is reasonable to have a discussion about the ISO situation
at that meeting. However, this meeting is our most important technical
decision-making meeting. I suggest that people who have opinions about the
ISO situation should try to send mail beforehand or try to formulate a
concise statement so that the normal business of the next meeting can be
conducted as planned.
-rpg-
∂12-Dec-88 0832 X3J13-mailer Re: ISO Meeting Status
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 08:32:52 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA08427; Mon, 12 Dec 88 08:35:20 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA08700; Mon, 12 Dec 88 08:32:00 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA05945; Mon, 12 Dec 88 08:32:35 PST
Message-Id: <8812121632.AA05945@suntana.sun.com>
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Cc: ROSENKING@a.ISI.EDU, x3j13@SAIL.Stanford.EDU
Subject: Re: ISO Meeting Status
In-Reply-To: Your message of 10 Dec 88 12:36:00 -0800.
<14Oq5E@SAIL.Stanford.EDU>
Date: Mon, 12 Dec 88 08:32:33 PST
From: kempf@Sun.COM
>All of the US ISO representatives will, I believe, be at the January X3J13
>meeting, and it is reasonable to have a discussion about the ISO situation
>at that meeting. However, this meeting is our most important technical
Considering the recent exchange of notes on the ISO Meeting, I think it would be
worthwhile to have this discussion. I also agree that it should be
arranged such that it does not conflict with the technical sessions,
as they are, at this point, more important. Perhaps we can schedule an
evening session for it.
jak
∂12-Dec-88 0942 X3J13-mailer Issue release & scheduling
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 09:42:06 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 09:31:01 PST
Date: 12 Dec 88 09:30 PST
From: masinter.pa@Xerox.COM
Subject: Issue release & scheduling
To: x3j13@sail.stanford.edu
Message-ID: <881212-093101-4200@Xerox>
I will be mailing out hardcopy of the "released" issues this week. If
there are errors, problems, or corrections to any of the issues--
especially the late-breaking ones-- please prepare amendments or new
versions to bring to the January meeting. While there will be a ballot, the
purpose of the ballot is to help us avoid discussing the non-controversial
issues; the ballot will tell us which issues should be included in a
"block" vote of endorsement/rejection. Certainly there will be opportunity
at the January meeting to correct mistakes or review issues, if there is
some belief that they were incorrectly framed, misunderstood, or should
otherwise be reviewed.
My personal schedule for getting the mailing out is tight enough that it is
likely there will be more of these than just the ones that JonL has pointed
out. Given the large number of issues, there's been more haste than usual,
for which I apologize.
After issues go into the mail, I will be on vacation until the new year, so
please do not expect a reply if you send mail to me alone.
∂12-Dec-88 0942 X3J13-mailer Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 09:42:14 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 09:34:46 PST
Date: 12 Dec 88 09:34 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-093446-4207@Xerox>
!
Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
References: CLtL p. 312-314
Category: CLARIFICATION
Edit History: V1, 5 Aug 1988, Sandra Loosemore
V2, 15 Sep 1988, Sandra Loosemore
V3, 7 Dec 1988, Masinter
Problem Description:
CLtL doesn't make clear whether defstructs that :INCLUDE another
structure type and do not specify a :PRINT-FUNCTION inherit the
:PRINT-FUNCTION of the parent structure type. While it is stated on
page 314 that #S syntax is used if a :PRINT-FUNCTION is not specified,
the language on page 313 indicates that all operations on the parent
type will also work on objects of the child type. Because of the
ambiguity, existing implementations have gone both ways, and users
cannot depend on either #S syntax or the parent type's :PRINT-FUNCTION
being used.
Proposal: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Clarify that defstruct types which :INCLUDE another type but do not
specify an explicit :PRINT-FUNCTION inherit the structure print
function from the :INCLUDE'd type. A print function that uses the
default #S syntax (overriding any print function for the parent type)
can be specified by providing the :PRINT-FUNCTION option without an
argument.
Supplying a :PRINT-FUNCTION in a DEFSTRUCT is equivalent
to defining an appropriate method on the PRINT-OBJECT generic
function.
Rationale:
Users typically specify a print function for a structure type because
its slots will contain circular objects or large internal data
structures which are confusing when printed. Any structure type that
:INCLUDEs this type will also contain the same slots; it seems more
reasonable to inherit the parent's print function than to use the
default #S syntax.
Current Practice:
Lucid Common Lisp makes structures inherit print functions.
VaxLisp uses #S syntax unless an explicit :PRINT-FUNCTION
is specified.
Cost to implementors:
The changes to non-conforming implementations should be fairly minor
and localized.
Cost to users:
It can't be any worse than the status quo.
Benefits:
An area of ambiguity in the language will be removed.
Discussion:
Pitman and VanRoggen support this proposal.
The original version of the proposal did not provide for a way to
force #S syntax to be used. This functionality was added to the
current version because there seemed to be general agreement that it
would be useful. Other alternatives would be to name the function
that does what the #S printer does, or to provide a function that
returns the #S information as a list (as suggested by Waters) so users
can write their own.
∂12-Dec-88 1004 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 10:04:29 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 09:55:34 PST
Date: 12 Dec 88 09:53 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-095534-4250@Xerox>
!
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References: CLtL p.308 & 86-003 p.4
Category: CLARIFICATION
Edit history: Version 1 by Skona Brittain 05/13/88
Version 2 by Larry Masinter 14-Sep-88
Version 3 by Larry Masinter 23-Sep-88
Version 4 by Larry Masinter 31-Oct-88
Problem Description:
The case of two slots of a structure having the same name is not
discussed in CLtL. Is it allowed?
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):
It is an error for two slots in a structure type to have the same symbol-name;
that is, the SYMBOL-NAME of the slot names should not be STRING=.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.
The situation of expanding a DEFSTRUCT macro with a duplicate name "should
signal an error." (While not yet formally defined, the intent is that
the error signalling may occur when compiling a file that contains
duplicate names or when evaluating a DEFSTRUCT form with duplicate names
in an interpreter.)
Examples:
(defstruct struc slot slot) would be an error. So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).
Rationale:
Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error.
Current Practice:
In KCL, if two slots have the same name, no warning message is
given but mysterious behavior ensues. (Their default values are
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the
second one's value can be changed by setf...)
Cost to Implementors:
None.
Cost to Users:
None.
Cost of Non-Adoption:
Possible confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
This issue was first circulated to X3J13 June 1988.
This proposal does not address the issue of whether NIL is a legitimate
slot name. There seems to be no current reason why it might be prohibitied.
The compiler committee is proposing to address generally the issue
of how macro-expansion errors during compile-file might be caught and
turned into compiler warnings.
∂12-Dec-88 1111 X3J13-mailer Issue: FIXNUM-NON-PORTABLE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 11:10:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 11:02:59 PST
Date: 12 Dec 88 10:49 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FIXNUM-NON-PORTABLE (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-110259-4502@Xerox>
!
Issue: FIXNUM-NON-PORTABLE
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 11-Jul-88, Sandra Loosemore
Version 2, 15-Sep-88, Masinter
Version 3, 23-Sep-88, Masinter
Version 4, 7-Dec-88, Masinter (two proposals)
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges. The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.
CLtL p14 and p34 disagree about BIGNUM. One says that
FIXNUM and BIGNUM are an exhaustive partition of the
integer space, the other says they might not be!
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) Define BIGNUM to be exactly (AND INTEGER (NOT FIXNUM))
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) remove the type BIGNUM from the language.
Example:
Consider an implementation with three numeric representations:
Fast (INTEGER -1024 1023)
Immediate 29 bits
Extended Multi-precision
Such an implementation would have to define
FIXNUM to be (OR Fast Immediate). BIGNUM, if it
remains, would then refer to multi-precision integers.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable.
However, there is little portable use for the type BIGNUM, and it
is inconsistent with many current implementation techniques.
Removing it is an incompatible change for a weak reason; thus
two proposals.
Current Practice:
Xerox Common Lisp has 17-bit fixnums. Most other Common Lisp
implementations have fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum
size.
Several existing Common Lisp implementations have more than two
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing; they define BIGNUM to cover all of the larger number
types.
Cost to implementors:
Slight. All implementations we know of already define FIXNUMs to be at
least 16 bits; TOSS-BIGNUM would have to remove the BIGNUM type
specifier to be in compliance with the proposal.
Cost to users:
Slight. The removal of the BIGNUM type specifier will affect user code
but it appears to be little-used.
Benefits:
The FIXNUM type specifier would have a portable interpretation.
The language would be less confusing.
Discussion:
There was little consensus on whether to leave BIGNUM in the language.
We don't currently have a way to "deprecate" features, so we are not
proposing it here.
Earlier discussion of a related proposal contained several other more controversial
components (adding a constant MAX-INTEGER-LENGTH, allowing
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree on.
It is possible that an implementation have a single representation for all
integers, and no way to identify any efficient range of integers. Those
implementations might need to set MOST-POSITIVE-FIXNUM
and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with
the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.
Other alternatives considered (and not necessarily mutually exclusive
with this proposal):
remove the FIXNUM type specifier entirely, while leaving a way
to query what is the most efficient range of integers
leave the range of FIXNUMs unconstrained and introduce a
SMALL-INTEGER type with a fixed range (but no promises about
efficiency) .
guarantee that the value of the constant ARRAY-TOTAL-SIZE-LIMIT be a
fixnum (for efficient array addressing)
It might be possible to specify the required performance behavior
of FIXNUMs more concretely, e.g., specify that the basic integer operations
use algorithms that are not proportional to the size of the data; it
should be just about as fast to add numbers in the middle of the fixnum
range as it is to add, say, 10 and 11. This might be a useful way to describe
the intent of the FIXNUM range, if not its specification.
----- End Forwarded Messages -----
∂12-Dec-88 1054 X3J13-mailer Issue: EXIT-EXTENT (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 10:53:55 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 10:39:04 PST
Date: 12 Dec 88 10:37 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: EXIT-EXTENT (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-103904-4431@Xerox>
!
Issue: EXIT-EXTENT
References: CATCH, THROW,
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Related issues: UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: ... Version 5 of UNWIND-PROTECT-NON-LOCAL-EXIT, 23-May-88 ...
Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter, minor edits
Version 3, 7-Oct-88, by Moon, wording improvements
Version 4, 7-Dec-88, by Masinter, add MEDIUM from
UNWIND-PROTECT-NON-LOCAL-EXIT, discussion.
Version 5, 12-Dec-88, Masinter, clarify MINIMAL allows MEDIUM
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
For example, at what point is it no longer possible to RETURN-FROM
a particular BLOCK?
(Terminology: In this issue writeup, the noun "exit" is
refera to the thing that can be exited from, rather than the
act of exiting. When the extent of an exit has ended, it is
no longer legal to exit from it. This is different from
the scope of the exit. For example, a BLOCK has lexical
scope but dynamic extent; a the scope of a CATCH--the
visibility of the CATCH tag to corresponding THROWs--
could differ from the extent of the CATCH.)
The problem arises when there are nonlocal exits from the
"cleanup" clauses of an UNWIND-PROTECT.
There are three cases of interest:
(1) Normal exit from a CATCH, BLOCK, or TAGBODY, or equivalent such as
PROG. A normal exit occurs when the last form in the body of one of
these constructs completes its evaluation without performing a transfer
of control.
(2) Nonlocal exit from the target of a THROW or RETURN. A nonlocal exit
occurs when control is transferred by THROW, RETURN, or RETURN-FROM.
The CATCH or BLOCK named in the THROW, RETURN, or RETURN-FROM is
referred to as the target. The TAGBODY containing the tag named by a
GO is also referred to as the target, but GO differs from the other
nonlocal control transfer operators because GO does not exit its target.
For example,
(3) Abandonment of an exit passed over by THROW, RETURN, or GO. A
CATCH, BLOCK, or TAGBODY that is dynamically nested inside the target of
a nonlocal transfer of control is said to be passed over when control is
transferred to the target. The target itself is not said to be passed
over.
For example, in
(block testem
(when (zilched) (return-from testem nil))
(when (zorked) (throw 'uh-oh))
(format t "Neither zilched nor zorked."))
if (zilched) returns true, the block testem is exited via a
'nonlocal exit'. If (zorked) returns true, the block testem
is 'passed over'. Otherwise, the block is exited normally.
The terms "normal exit", "target", and "passed over" will be used with
these meanings for the remainder of the discussion.
CLtL is unambiguous about case 1. In case 2, the extent could end
anywhere from the time the THROW or RETURN commences, until the time the
transfer of control is completed. In case 3, the extent could end
anywhere from the time the THROW, RETURN, or GO commences, until the
time the transfer of control is completed. In case 2, it is clear that
the extent of the target ends before the transfer of control completes,
since a block cannot be exited twice, but it is not made clear whether
the extent ends before or after execution of UNWIND-PROTECT cleanup
forms. CLtL says nothing about case 3, although a note on p.38 implies
that the extent of a passed-over exit should end no later than the end
of the extent of the target exit. It would make sense for the extent
of an exit passed-over by GO to end no later than when the transfer of
control is completed, but CLtL says nothing about this.
!
Proposal (EXIT-EXTENT:MINIMAL):
The dynamic extent of an exit, whether target or passed-over, ends as
soon as the THROW, RETURN, or GO commences. In the language of the
implementation note on p.142, the extent ends at the beginning of the
second pass. It is an error for an UNWIND-PROTECT cleanup form executed
during a nonlocal transfer of control to attempt to use an exit whose
dynamic extent ended when the nonlocal transfer of control commenced.
Note that this does not affect the extent of the binding of CATCH
tags; that is, under this proposal, a THROW to a CATCH which was
already in the process of being exited would be an error.
This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL. A program that presumed a longer extent
would be in error. Implementations may support longer extents for
exits than is required by this proposal; in particular, an
implementation which allowed the larger extent of the MEDIUM
proposal below would still conform.
Proposal (EXIT-EXTENT:MEDIUM):
The dynamic extent of an exit, whether target or passed-over, ends
only after the exit is complete.
A transfer of control from within an UNWIND-PROTECT cleanup form
to a point outside of the UNWIND-PROTECT causes the original control
transfer which initiated the execution of the cleanup forms to be
abandonded.
During the execution of the cleanup forms of an UNWIND-PROTECT a
non-local exit to a point outside of the scope of the UNWIND-PROTECT,
but still within the dynamic scope of of the target of the original
non-local exit succeeds, and the original pending exit is discarded.
Where an UNWIND-PROTECT cleanup form attempts a non-local exit to a
point outside the original non-local exit, control is passed to the
outer exit (and the pending original non-local exit is discarded.)
In no case will UNWIND-PROTECT cleanup forms ever be attempted more
than once.
!
Examples:
Each of the following programs are an error under either
proposal:
;; Error: BLOCK has normal exit before RETURN
(funcall (block nil #'(lambda () (return))))
;; Error: normal exit before GO
(let ((a nil))
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
;; Error: TAGBODY is passed over, before GO
(funcall (block nil
(tagbody a (return #'(lambda () (go a))))))
Each of these programs are an error under MINIMAL, but
not under MEDIUM:
;;returns 2 under MEDIUM, is error under MINIMAL
(block nil
(unwind-protect (return 1)
(return 2)))
;;returns 2 under MEDIUM, is error under MINIMAL
(block a
(block b
(unwind-protect (return-from a 1)
(return-from b 2))))
;; returns 2 under MEDIUM, is error under MINIMAL
(catch nil
(unwind-protect (throw nil 1)
(throw nil 2)))
;; returns 2 under MEDIUM, is error under MINIMAL
(catch 'a
(catch 'b
(unwind-protect (throw 'a 1)
(throw 'b 2))))
;; An error under MINIMAL because the catch of b is passed over by
;; the first throw, hence portable programs must assume its dynamic extent
;; is terminated. The catch is not yet disestablished and therefore it
;; is the target of the second throw.
;; the following is an error under MINIMAL; the extent of the
;; inner catch terminates as soon as the throw commences, even
;; though it remains in scope. Thus, the throw of :second-throw
;; sees the inner catch, but its extent has ended.
;; under MEDIUM, it prints "The inner catch returns :second-throw"
;; and then returns :outer-catch.
(catch 'foo
(format t "The inner catch returns ~s.~%"
(catch 'foo
(unwind-protect (throw 'foo :first-throw)
(throw 'foo :second-throw))))
:outer-catch))
The following program is not an error. It returns 10. The inner
catch of a is passed over, but this is not case 3 because that catch
is disestablished before the throw to a is executed.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
The following cases are errors under MINIMAL, and have
the following interpretation under MEDIUM:
In
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
the pending exit to tag FOO is discarded by the second THROW
to BAR and the value 4 is transfered to (CATCH 'BAR ...),
which returns 4. The (CATCH 'FOO ...) then returns the 4
because its first argument has returned normally.
XXX is not printed.
In
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
the value 4 is returned from the (CATCH 'BAR ...); XXX is not printed.
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. It is not an error, even though the
BAR tag is not found within the local dynamic scope of
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found outside the scope of the target of the
pending THROW to FOO.
Rationale:
For MINIMAL: Giving exits the smallest extent consistent with CLtL
maximizes freedom for implementations; there are few applications,
if any, that require a longer extent.
For MEDIUM: Giving exits a longer exent has cleaner semantics.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target block or catch at the moment the values are returned, and
end the extent of a passed-over exit at the moment the THROW, RETURN, or
GO commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, the extent of a target exit lasts until the
exit has been completed; in those implementations, it is possible for a
throw or non-local exit to be effectively "stopped" by an UNWIND-PROTECT
cleanup clause that performs a nonlocal transfer of control to a
passed-over exit.
Some implementations crash or otherwise generate garbage code for
non-local exits from cleanup clauses of UNWIND-PROTECT.
Cost to Implementors:
No currently valid implementation will be made invalid by the MINIMAL
proposal. Some implementors may wish to add error checks if they
do not already have them.
MEDIUM would have a high cost for those implementations that currently
have shorter exent.
Cost to Users:
Most user programs don't do this, so there is likely little cost
of converting existing code in any case. In any case, current implementations
differ enough that this issue ostensibly does not
affect current portable programs. Some users might have code that
relies on the "unstoppable loops" that can be created with the MEDIUM
proposal.
Benefits:
Either proposal would make Common Lisp more precisely defined.
Cost of non-adoption :
The semantics of exits will remain ambiguous.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
This issue is controversial. It was first discussed under the issue
named UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT. The issue was recast as
the more global one of "extent of exits" rather than the specific
one of "what happens if a cleanup in an UNWIND-PROTECT does a non-
local exit", but the problem cases for both topics are the same.
The goal of the MINIMAL proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. The MEDIUM proposal
defines the extent of an exit to end at the last moment possible
within some particular reference implementation. It has
a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal, not considered
here, would duck the issue by outlawing all nonlocal exits from UNWIND-PROTECT
cleanup forms. That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
An argument for the MEDIUM proposal was made based on the example:
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
Since there is no reason for FOO and BAR not to be treated interchangably,
calling this an error would be inappropriate.
It was argued that the MINIMAL proposal is equivalent to practically
outlawing non-local exits from UNWIND-PROTECT cleanup clauses, because
there is no general way to determine the target of the nonlocal exit
that caused the cleanup clause to be invoked.
CLtL never says in what dynamic environment cleanup forms of
UNWIND-PROTECT are executed. The implementation note on p.142 may have
been intended to cover this, but since it doesn't define the term
"frame" that it uses, it doesn't actually say anything. The extent of
dynamic-extent entities other than exits should be the
subject of a separate proposal. It was argued that the likely
resolution of those issues would be more consistent with the
MEDIUM proposal than MINIMAL.
The following example was offered as an argument against MINIMAL. Given:
(block nil
(handler-case
(unwind-protect (return)
(error "foo")) ;probably an error, under the proposal
(error ()
(print "foo"))))
If the ERROR handler has the same scope and extent a CATCH in the same place
would have (and that seems reasonable, though I'm not certain that the
condition system specifically requires that interpretation), then the handler
will be apparent to the call to ERROR, but will no longer be a valid target
(its extent was exited by the RETURN in the UNWIND-PROTECT body).
----- End Forwarded Messages -----
∂12-Dec-88 1129 X3J13-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 11:29:08 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 11:19:43 PST
Date: 12 Dec 88 11:19 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-111943-4569@Xerox>
!
Forum: Cleanup
Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
References: CLtL pp 47-48, 158-159
Category: CHANGE
Related-issues: DECLARE-TYPE-FREE
Edit history: #1, 7 Sept 1988, Walter van Roggen
#2, 13 Sept 1988, Walter van Roggen (costs & proposal limitations)
#3, 7-Dec-88, Masinter
Problem description:
The current description of the specialized FUNCTION type specifier is not very
useful to program analysis tools and is not very intuitive to programmers
because the meaning of the argument type specifiers is not restrictive.
Programmers find it useful to add information about the types of the arguments
a function expects and about the type(s) that a function may return. This
information is useful both to human readers of the code as well as to type
checking programs such as compilers and cross referencers. The only apparent
way of providing this information is with the FTYPE declaration
or the FUNCTION type specifier.
Furthermore, implementations may wish to provide additional optimizations based
on avoiding type checking or different methods of argument passing. These
optimizations require the same sort of information about the argument types.
However, the current definition of FUNCTION type specifiers on pages 47-48 of
CLtL states that a function such as CONS that is of type
(FUNCTION (T T) CONS)
is also of type
(FUNCTION (FLOAT STRING) LIST).
The problem is that the argument types aren't restrictive, so no interesting
matching of types is possible.
Proposal (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE)
This proposal is written as if DECLARE-TYPE-FREE (Version 6, 06-Oct-88)
is in effect.
Specify that a declaration of the form
(ftype (function (arg0-type arg1-type ...) val-type) f))
implies that any call of the form (f arg0 arg1 ...) within the scope of
the declaration can be treated as if it were
(the val-type (f (the arg0-type arg0) (the arg1-type arg1) ...))
That is, it is an error for any of the arguments not to be of the specified
types or the result not to be of the specified type. (In particular,
If any argument is not of the correct type, the result is not guaranteed
to be of the specified type.)
Thus, an FTYPE declaration for a function describes calls to the function,
not the actual definition of the function.
Similarly, specify that a declaration of the form
(type (function (arg0-type arg1-type ...) val-type) fn-valued-variable)
has the interpretation that, within the scope of the declaration, it
is an error to call the value of fn-valued-variable with arguments
not of the specified type; assert that the value resulting from a valid
call will be of type val-type.
As with variable type declarations (cf DECLARE-TYPE-FREE), nested declarations
imply intersections of types, as follows:
If two (or more) declarations of the form "ftype" are in effect,
(ftype (function (arg0-type1 arg1-type1 ...) val-type1) f))
and
(ftype (function (arg0-type2 arg1-type2 ...) val-type2) f))
then within the shared scope of the declarations, calls to f can be
treated as if it were declared
(ftype (function ((and arg0-type1 arg0-type2) (and arg1-type1 arg1-type2 ...) ...)
(and val-type1 val-type2))
f))
(It is legitimate to ignore one or all of the declarations in force.)
If two (or more) type declarations are in effect for a variable, and
they are both FUNCTION declarations, the declarations combine similarly.
This proposal does not alter the status (or lack thereof) of other issues
related to FUNCTION type specifiers: what lambda-list keywords mean, what the
VALUES type means, what implications there are w.r.t. argument counts, doing
multiple PROCLAIMs, doing local DECLAREs that shadow other declarations or
proclamations, describing generic functions incrementally, the result of TYPEP
with a specialized FUNCTION type, or the nesting and scoping rules for
FTYPE declarations.
Example:
(DEFUN FFF (F)
(DECLARE (TYPE (FUNCTION (FLOAT STRING) LIST) F))
... (FUNCALL F (FOO ...) ...) ... )
then #'CONS is a valid argument to be passed to FFF because the declared
type of the argument is consistent with type (FUNCTION (T T) CONS).
Within FFF, the declaration permits us, for example, to assume that FOO
returns a FLOAT.
Rationale:
The proposal seems most like what users expect.
Current Practice:
VAX LISP assumes and makes use of the semantics different than CLtL
but not exactly what is specified here. Lucid
has a RESTRICTIVE-FTYPE declaration with these semantics and ignores the
standard FTYPE declaration. Gold Hill intends to use these declarations in this
manner. Many implementations don't make use of these declarations. At least
several users make use of declarations assuming the new semantics.
Cost to Implementors:
Since most implementations don't make use of function declarations, and since
those known to do so can be changed easily, the cost should be minimal.
Cost to Users:
There may be some existing "imprecise" function declarations. However, the
natural tendency when providing these declarations is to be as "descriptive"
(i.e., restrictive but complete) as possible, both for documentation purposes
as well as for potential compiler benefits. There cannot have been any uses of
the specialized FUNCTION type for discrimination. Thus most existing uses are
probably compatible with this new definition.
Cost of Non-Adoption:
There already exists user code on many implementations that assume the
proposed semantics. Not adopting this proposal would continue to render
such code incorrect or at least non-portable.
Benefits:
Better type checking and more compiler optimizations should be possible.
Esthetics:
This is the what most programmers expect the specialized FUNCTION type to
mean, particularly those coming from other languages.
Discussion:
A declaration of
(FUNCTION (FIXNUM FIXNUM) CONS)
is a not proper global declaration for CONS if any program might
call CONS with arguments that are not FIXNUM.
The list form of the FUNCTION type specifier is different from most
type specifiers because it cannot be used for discrimination.
Thus, the notion of "subtype" does not make sense, since assertions
about the functional value of a variable are only partially
about the actual value of the variable and mainly about the
values that might be passed to the variables (function) value.
∂12-Dec-88 1129 X3J13-mailer Issue: FUNCTION-COMPOSITION (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 11:29:00 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 11:17:46 PST
Date: 12 Dec 88 11:04 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FUNCTION-COMPOSITION (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-111746-4560@Xerox>
!
Forum: Cleanup
Issue: FUNCTION-COMPOSITION
References: None
Category: ADDITION
Edit history: 21-Jun-88, Version 1 by Pitman
05-Oct-88, Version 2 by Pitman
7-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter (additional comments)
Related-Issues: TEST-NOT-IF-NOT
Problem Description:
A number of useful functions on functions are conspicuously
absent from Common Lisp's basic set. Among them are functions
which return constant T, constant NIL, and functions which
combine functions in common, interesting ways.
Proposal (FUNCTION-COMPOSITION:NEW-FUNCTIONS):
Add the following functions:
COMPOSE &REST functions [Function]
Returns a function whose value is the same as the composition
of the given functions. eg, (FUNCALL (COMPOSE #'F #'G #'H) A B C)
is the same as (F (G (H A B C))). Also, for example, #'CAADR may
be described as (COMPOSE #'CAR #'CAR #'CDR).
CONJOIN &REST functions [Function]
Returns a function whose value is the same as the AND of the
given functions applied to the same arguments.
DISJOIN &REST functions [Function]
Returns a function whose value is the same as the OR of the
given functions applied to the same arguments.
COMPLEMENT function [Function]
Returns a function whose value is the same as the NOT of the
given function applied to the same arguments.
ALWAYS value [Function]
Returns a function whose value is always VALUE.
Proposal: FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Only add the functions COMPLEMENT and ALWAYS.
Examples:
(MAPCAR #'(LAMBDA (X) (DECLARE (IGNORE X)) T) '(3 A 4.3))
==
(MAPCAR (ALWAYS T) '(3 A 4.3))
=> (T T T)
(MAPCAR #'(LAMBDA (X) (AND (NUMBERP X) (ZEROP X))) '(3 A 0.0))
==
(MAPCAR (CONJOIN #'NUMBERP #'ZEROP) '(3 A 0.0))
=> (NIL NIL T)
(FIND-IF #'(LAMBDA (X) (AND (INTEGERP X) (SYMBOLP X))) '(3.0 A 4))
==
(FIND-IF (DISJOIN #'INTEGERP #'SYMBOLP) '(3.0 A 4))
=> A
(FUNCALL #'(LAMBDA (&REST X) (REVERSE (APPLY #'LIST* X))) 3 4 5 '(6 7))
==
(FUNCALL (COMPOSE #'REVERSE #'LIST*) 3 4 5 '(6 7))
=> (7 6 5 4 3)
(FIND-IF-NOT #'ZEROP '(0 0 3))
==
(FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
=> 3
Rationale:
The presence of these functions will contribute to syntactic
conciseness in some cases. The NEW-FUNCTIONS proposal
will permit a programming style which is currently awkward
in most Common Lisp implementations.
Current Practice:
No Common Lisp implementations provide these functions,
but they do exist in the T language.
Cost to Implementors:
A straightforward implementation is simple to cook up. The definitions
given here would suffice. Typically some additional work might be
desirable to make these open code in interesting ways.
(DEFUN COMPOSE (&REST FUNCTIONS)
(COND ((NOT FUNCTIONS)
(ERROR "COMPOSE requires at least one function."))
((NOT (REST FUNCTIONS))
(FIRST FUNCTIONS))
(T
(LET ((REVERSED-FUNCTIONS (REVERSE FUNCTIONS)))
(LET ((LAST-FUNCTION (FIRST REVERSED-FUNCTIONS))
(OTHER-FUNCTIONS (REST REVERSED-FUNCTIONS)))
#'(LAMBDA (&REST ARGUMENTS)
(DO ((O OTHER-FUNCTIONS (CDR O))
(VAL (APPLY LAST-FUNCTION ARGUMENTS)
(FUNCALL (CAR O) VAL)))
((NULL O) VAL))))))))
(DEFUN CONJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL T (AND VAL (APPLY (CAR F) ARGUMENTS))))
((OR (NULL VAL) (NULL F)) VAL))))
(DEFUN DISJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL NIL (OR VAL (APPLY (CAR F) ARGUMENTS))))
((OR VAL (NULL F)) VAL))))
(DEFUN COMPLEMENT (FUNCTION)
#'(LAMBDA (&REST ARGUMENTS)
(NOT (APPLY FUNCTION ARGUMENTS))))
(DEFUN ALWAYS (VALUE)
#'(LAMBDA (&REST ARGUMENTS)
(DECLARE (IGNORE ARGUMENTS))
VALUE))
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
(COMPLEMENT BENEFITS)
Benefits:
Some code would be more clear.
Some compilers might be able to produce better code.
Takes a step toward being able to flush the -IF-NOT functions
and the :TEST-NOT keywords, both of which are high on the list
of what people are referring to when they say Common Lisp is
bloated by too much garbage.
Aesthetics:
In situations where these could be used straightforwardly, the
alternatives are far less perspicuous.
Discussion:
It is technically possible to define this functionality portably,
the really important part of this proposal is that native compiler
support is needed to really do them justice. Portable implementations
are not likely to be efficient enough for serious use.
Placing these functions in the core language not only permits
but encourages a very useful set of compiler optimizations that
would otherwise be difficult to obtain.
In principle, a proposal to flush the :TEST-NOT keywords and the
-IF-NOT functions could even be entertained if the COMPLEMENT
function were added. [See issue TEST-NOT-IF-NOT.]
Pitman and van Roggen support the proposal.
Jim McDonald (JLM@Lucid.COM) seemed supportive of this proposal
and even suggested adding more elaborate operators such as
PERMUTE and COMMUTE. eg, (COMMUTE #'CONS) would be like what
Maclisp called XCONS.
Other comments:
"I don't like it. I really don't."
The names chosen are too "generic"; pick other names.
No existing implementations have functions like these, although they
could easily have added them.
If COMPOSE is added, deal with multiple values, e.g.,
(funcall (multiple-value-compose #'f #'g #'h) a b c)
is the same as
(multiple-value-call #'f
(multiple-value-call #'g
(h a b c)))
"this is the sort of gratuitious addition to the
language that ought to be tested first -- tested by it's utililty to some
vendor/implementor who feels it's worth the risk to add something like it
to his product. I deplore the tendency to think that vendors shouldn't make
an offering unless it is "sanctioned" by the X3J13 committee."
Additional Comments:
"The names are OK with me except for ALWAYS. ALWAYS reminds me of the
SOME/EVERY/etc. mapping functions, perhaps because it's a LOOP keyword
(btw, what's the status of LOOP keywords?). I would prefer something
like RETURNER. Also, I presume it's defined as taking (&rest ignore)
for an arglist. Is that true? Shouldn't that be specified in the proposal?"
"Although the discussion mentions some criticism from within the subcommitte,
I don't think it does full justice. ....
. . .
I say "gratuitious" because
(1) no vendor/implementor supplies them now; thus it is not "existing
practice" that needs to be standardized;
(2) no fundamental problem has been exposed because of its lack; no
implementational headaches would be resolved, and few (if any) pleas
from the user community would be addressed;
(3) no confusions exists among our community as to what these functionals
(or similar such features) mean; hence no need to clarify.
. . .
While it is useful to encourage the "functional style" of programming,
these functions are *not nearly enough* to do that. That is, if you really
wanted to build a useful library, you would find these few functions
inadequate.
Extensions that no current vendor offers -- even those that have extensive
sets of extensions to Common Lisp in their product -- should be viewed with
great suspicion.
"
∂12-Dec-88 1212 X3J13-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 12:12:28 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 12:11:02 PST
Date: 12 Dec 88 12:10 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-121102-4751@Xerox>
!
Issue: IN-PACKAGE-FUNCTIONALITY
References: IN-PACKAGE (p183)
Category: CHANGE
Edit history: 07-Jul-88, Version 1 by Pitman
7-Oct-88, Version 2 by Masinter (discussion)
8-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter
Related-Issues: DEFPACKAGE
Problem Description:
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):
Eliminate the ability of IN-PACKAGE to create a package on demand.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
The results of calling IN-PACKAGE if the package does not already
exist are implementation dependent; implementations "should signal"
an error, or otherwise provide the user with a way to recover from
the situation.
Examples:
#1: (IN-PACKAGE 'NO-SUCH-PACKAGE) ;would signal an error
#2: (DEFPACKAGE FOO ...options...) ;defines/creates a package
(IN-PACKAGE 'FOO) ;selects an existing package
Rationale:
This could allow improved error checking and modularity, with only minimal
loss of functionality.
Current Practice:
Probably no one implements this behavior since it's in direct
contradiction of both the definitions and numerous examples in CLtL.
Cost to Implementors:
As written, no change to implementations is required, but many
will want to make IN-PACKAGE signal an error.
This change would be straightforward to implement.
The cost may not be trivial in all cases, but should not be very large.
Cost to Users:
In most cases, minor syntactic changes to some files would be necessary.
In some cases, no changes would be necessary since files may already be
doing IN-PACKAGE in situations where the author is hoping he's made sure
the real package declaration is already loaded.
Cost of Non-Adoption:
Reduced error checking.
Less modular code.
Benefits:
Errors due to demand-creation of a package by IN-PACKAGE without appropriate
uses of the :USE or :NICKNAMES or without appropriate calls to EXPORT, etc.
afterward would be easier to detect.
Modular package declarations would be encouraged.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether the
package should exist already or not) is clearly not aesthetic. This change
would be an aesthetic improvement.
Discussion:
The dual use of IN-PACKAGE has not been helpful and is confusing.
Some support this only if DEFPACKAGE passes; others would like
to see IN-PACKAGE changed even if DEFPACKAGE were not added to the language.
However, there might be some compilation problems if IN-PACKAGE
changes and MAKE-PACKAGE signals an error if the package exists.
The issue of compile-time processing of package related functions is
complex, and full of a number of compatibility issues. Should we remove
the requirement of special compile-time handling of IN-PACKAGE?
Should we disallow mid-file switching of *PACKAGE* or package
use lists? These issues are not addressed here.
The issue of the "proper" preface for files needs more thought.
Should files that need demand-created packages start with DEFPACKAGE
followed by IN-PACKAGE?
".... unless the file begins with an
IN-PACKAGE, then the DEFPACKAGE form will be read into totally random
package, doing who knows what sort of damage.
Ideally, every file of a multi-file module should begin with an
IN-PACKAGE form to get "in" that module's package. The exceptions
are files which might as start out (IN-PACKAGE "USER"). For example,
the package creator file might look something like:
(in-package "USER") ;guaranteed to exist, and not be harmful!
(defpackage :phlogiston ...)
Another exception might be the DEFSYSTEM surrogate, which also would
start out in the USER package, and simply load the rest of the files."
∂12-Dec-88 1212 X3J13-mailer Issue: HASH-TABLE-STABILITY (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 12:12:16 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 11:51:33 PST
Date: 12 Dec 88 11:51 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: HASH-TABLE-STABILITY (Version 1)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-115133-4704@Xerox>
This issue has "additional comments" at the end that are not
part of this version.
!
Issue: HASH-TABLE-STABILITY
References: CLtL, p.282 "Hash on Lisp object"
The Art of Computer Programming, vol 3, Section 6.4 "Hashing"
Category: CLARIFICATION
Edit history: Version 1, 11-Nov-88, by JonL
Problem description:
The performance, and to some degree the semantics, of hash tables
depends not only on the kind of table as specified by the :test
argument to MAKE-HASH-TABLE, but also on the underlying techniques
of key transformation (into an integer) and of "collision" resolution.
CLtL is not specific enough to encompass current, desirable practice.
People tend to be confused as to what "Hash on EQ" means, both in terms
of semantics and expected performance. Many will often suggest using
SXHASH as the key-transformation function for EQ/EQL type tables, in
order to circumvent the well-known GC-related problem with those tables.
[See, for example, the message from Barry Margolin to the common-lisp
mailing list dated "12 Sep 88 11:05 EDT"; it is reproduced at the end of
the Discussion section below.] Unfortunately, this suggestion violates
the commonly perceived notion of what "Hash on EQ" means, even though
CLtL nowhere explicitly would rule it out. CLtL is not precise enough
as to what is expected of these types of tables, and certainly the
phrase "commonly perceived notion" is not precise enough.
A similar ambiguity can arise as to what "Hash on EQUAL" means; CLtL
p.285 only indirectly implies that SXHASH should be used as the
key-transformation function for EQUAL type tables. [See below for
definition of "key-transformation".]
The term "Hashing on Lisp objects" has come to be called "Hash on EQ",
and "Hashing on Tree Structure" is called "Hash on EQUAL"; see CLtL
p.282 , which describes the differences between hash-table kinds as
being merely which function they use as the equivalence predicate
(the :TEST function argument to MAKE-HASH-TABLE.) However, the term
"Hash Table" carries a strong connotation about how such a table is
implemented; in particular, for sufficiently large tables, some technique
for "collision resolution" must be done. (See Knuth vol 3, p507-8).
Since CLtL merely focuses on the :test function, people -- implementors
as well as end-users -- tend to be confused as to how these techniques
play a central part in the notion of "hash tables; furthermore, CLtL is
silent about what actions must preserve the stabililty of these
"collision chains" (i.e., the ability of the table to "find" previously
entered keys).
Proposal (HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS)
Summary of proposals:
-- Clarify that by "hashing", we mean more than simple linear search.
-- Generalize the following requirement from CLtL p.285:
(EQUAL X Y) implies (EQUAL (SXHASH X) (SXHASH Y))
and clarify that this requirement exactly prescribes how sensitive
hash tables can be to user-initiated data modifications.
-- Characterize just what key-transformation functions may be used for
EQ, EQL, EQUAL and EQUALP hash tables.
First, some terminology:
"Key-Transformation". This is a term used by Knuth to describe the
homomorphic transformation of a hash-table key argument into an integer.
[See the index for "The Art of Computer Programming", vol 3; especially
see Section 6.4 and page 512.] It also can refer to the transformation
into a set of two or more integers (which is not really a distinct
notion considering Goedel numbering). From this integer, the pattern
of table indices to use when searching for that key will be completely
characterized. Knuth also uses a related term "hash function" to mean
"the address where the search begins"; that term is much too subject to
confusion, and will not be used herein.
"Collision Chain". This term is limited in use by Knuth to just one
particular method of collision resolution; herein it will be used to
describe the sequence of probes specified for a given candidate entry
by a particular key-transformation; i.e. a virtual "chain" of table
indices (or address) to be examined. Two different objects which "hash"
to the same table address are "in conflict", and their respective
collision chains may or may not be equal.
"Expected number of (re-)probes". A particular algorithm for key-
transformation and collision-chain specification could be analyzed to
show a graph of the "Expected" number of calls on the :test function,
as a function of the fullness of the table (number of entries divided
by table size). "Expected" has a technical, mathmatical meaning here:
it basically means "average", so one must be careful not to get carried
away with particular counter examples of "badly distributed" data. A
"probe" is one comparison of the argument with the key of an entry in
the table, using the test function.
"%UNIQUE-NO". The implementation of Lisp data, encoded into machine-
specific data and addresses, is not part of the portable specification
of CL; but we are aware that every implemetation _must_ do some such
embedding. Thus we will use %UNIQUE-NO to name a one-to-one function
which maps any Lisp object into a Lisp integer. Normally, this will
just be the machine address of where the object is stored, possibly with
some data-type tag bits added. But for non-stored, or "immediate" data,
it doesn't matter what %UNIQUE-NO returns as long as its bijective nature
is maintained. The following equivalence is a defining characterization:
(eq x y) <--> (= (%unique-no x) (%unique-no y))
Now for the actual proposals.
1. Clarify that the term "hash table" implies the use of some techniques
designed to make the expected number of probes be bounded by a small
constant rather than growing linearly with the number of entries in the
table [for "small constant", one could also accept "log of the number of
entries"]. Although nothing in CLtL explicitly prohibits it, very few
people would accept simple linear searching as any kind of hash table.
For example, the following definition is counter to our understanding:
(defun gethash (x ht &optional default)
(let ((index (position x (hash-table-key-vector ht)
:test (hash-table-test ht))))
(if index
(values (svref (hash-table-value-vector ht) index)
T)
(values default
NIL))))
Such a simple definition may be functionally useful when the total
number of entries is small (e.g., a couple dozen or so); but the
"Expected" number of probes grows linearly with the number of entries.
As a consequence of this requirement, the collision chain for a give item
in a given table will likely not cover the whole table; otherwise, if
every such chain covered a substantial fraction of the table, then the
behaviour time would be linear in the size of the table. Thus it should
be noted that even though an item is entered in a hash table, it
typically _cannot_ be found by searching through the wrong collision
chain.
2. Specify that for any equivalence relation <eqv> used as a hash table
:test function, there must be a corresponding key-transformation function
<sxh> used in that hash table such that the following implication is true
for all X and Y:
(<eqv> x y) --> (= (<sxh> x) (<sxh> y))
This could be said to mean that a key-transformation function must be "not
more discriminating" than the equivalence function it is associated with;
i.e. as a numerical function, it must not create more equivalence classes
of data than the associated equivalence function does.
This requirement resembles that placed upon SXHASH [CLtL, p285], and
from it, one may deduce that SXHASH is a acceptable key-transformation
function for EQUAL type hash tables. Note well, however, that there
are many many functions satisfying this property for EQUAL. Hence
key-transformation for EQUAL tables:
(1) need not be constant over all CL implementations;
(2) need not be constant over all instances of EQUAL hash-tables in
a given implementation;
(3) need not be constant even over all entry counts for a particular
hash table in a given implementation.
Note also that this requirement -- "not more discriminating" -- rules
out the use of key-transformations which "notice" data modifications
that are not likewise "noticed" by the test function. Since user-
initiated data modifications might conceivably affect either the
equivalence relation of a hash-table (the :test function) or the
associated key-transformation function, we want to ensure that the
ability of the table to "find" a previously entered key is related only
to the ability of the :test function to identify equivalent copies of
the key.
3. Clarify that %UNIQUE-NO is acceptable as a key-transformation for an
EQ type table, but that it is not suitable for EQUAL or EQUALP tables.
Clarify also that most SXHASH implementations are _not_ suitable for EQ
or EQL type tables.
Numerous implementations have some function like %UNIQUE-NO called
either %POINTER or POINTER-TO-FIXNUM; they are generally acceptable for
EQ type tables. But one must be careful to note that similar, unrelated
functions could also be used; in particular, many "unique identification"
schemes have been employed where the integer is cached with the object by
some means other than the bits of its address (e.g. a "hidden" component
inside the object). Of course, any %UNIQUE-NO defined as above would not
be acceptable for EQUAL or EQUALP tables; two EQUAL but non-EQ cons cells
must have different %UNIQUE-NO values, violating the general rule stated
in item 2 above.
A trivial variant on %UNIQUE-NO is acceptable for EQL tables:
(if (numberp x) (sxhash x) (%unique-no x))
By itself, %UNIQUE-NO would not be acceptable since it would be too
"discriminating" on numbers.
Many persons have noted that the definition:
(defun sxhash (x) 5) ;for any random integer value of "5"
meets the CLtL criterion for SXHASH. In fact, such a constant function
may be quite useful for hash-tables with entry counts below a specified
mininum. But of course it is not really suitable in general since it
would put every entry into the same collision chain; that would cause
the expected re-probe cost to be linear in the number of entries, which
violates item 1 above.
On the other hand, an SXHASH function suitable for use as the key
transformation in an EQUAL type table is _not_ acceptable for use
with an EQ or EQL table. Every implementation the proposer has queried
returns different values for the lists (A) and (B). Thus consider the
example of hashing a list (A) into an EQ type table, and observe what
happens after altering the (first) element of this list to be B. Let
x = the list before modification
y = the list after modificaton
now clearly (EQ X Y) is true, so we would obviously like a GETHASH call
after the modification has been done to find the same cons cell that
had been entered before the update. If SXHASH were used as the key-
transform, then the collision chain selected _after_ the alteration would
be different from the one selected beforehand. Since the two different
collision chains can not be guaranteed to intersect, then in at least
some circumstances, GETHASH on X would find the entry, but GETHASH on Y
would fail to find it. See also the examples section.
Although SXHASH is not very tightly defined in CLtL, one must be careful
not to make assumptions about whether or not it is acceptable for use in
EQUALP tables. In order to get a reasonable amount of randomization in
the collision chains, a key-transformation function for EQUAL tables
ought to be "more discriminating" than any minimal function acceptable
for EQUALP tables [because EQUAL partitions the object world up into
many more equivalence classes than does EQUALP].
In item 2 above, there are listed three areas where key-transformation
functions may differ: when going from one vendor to another (or from one
release by the same vendor to another), when going from one hash-table
to another of the same type, and when increasing or decreasing the entry
count of the table. To this list we can add another more general rule on
key-transformations.
(4) [they] need not be constant even over a particular "core image"
saving and restoration, or over a "memory reorganization" such as
a garbage collection.
Of course, if a change is made at some point in time in the key-
transformation algorithm being used for a particular table, then that
table should be "re-hashed" to ensure the continuity of its entries.
As has been noted before, many implementations use algorithms for EQ
type tables which change after any data is relocated; that is why
re-hashing may be required after a "GC".
Examples:
It is not surprising that in the following example, the value Y
cannot be found in the table after it has been altered by the first
SETF, even though it could be found before the alteration.
(setq ht (make-hash-table :test 'equal)) ==> #<Hash-Table>
(setq x '(A (B) (C D))
y (copy-tree x)) ==> (A (B) (C D))
(and (equal x y) (not (eq x y))) ==> T
(setf (gethash x ht) T) ==> T
(setf (car (second y)) 'E) ==> E
(gethash x ht) ==> T
(gethash y ht) ==> NIL
After all, the :test function will not be able to identify the
altered key with with the one originally entered, because at the
time gethash is called:
(equal x y) ==> NIL
However, the circumstances under which the following can fail are
not at all obvious:
(setq ht (make-hash-table :test 'equal)) ==> #<Hash-Table>
(setq x '(A #(B) (C D))
y (copy-tree x)) ==> (A #(B) (C D))
(and (equal x y) (not (eq x y))) ==> T
(setf (gethash x ht) T) ==> T
(setf (aref (second y)) 'E) ==> E
(gethash x ht) ==> T
(gethash y ht) ==> ?
Note however that:
(equal x y) ==> T
If the key-transformation function used in this hashtable failed to obey
the "not more discriminating" contraint imposed by item 2 above, it
might be tempted to descend into the vector #(B) in order to randomize
the keys a bit more; but EQUAL on pointer vectors is defined to be EQ.
Thus X and Y, while being EQUAL, might fall into different collision
chains, and hence not be identified as the same key.
On the other hand, EQ/EQL type tables should be impervious to the
updates in the above examples:
(setq ht (make-hash-table)) ==> #<Hash-Table>
(setq y (setq x (copy-tree '(A (B) (C D))))) ==> (A (B) (C D))
(setf (gethash x ht) T) ==> T
(gethash x ht) ==> T
(setf (car (second y)) 'E) ==> E
(gethash y ht) ==> T
Thus x and y are "EQ, but not EQUAL" [which only makes sense when
they refer to the same object at different points in time]; however,
the EQ/EQL-type table is not affected by this.
Rationale:
The performance expectations about hash-tables, and consequent
implementational constraints, need to be formalized.
Current practice:
Every implementation that the proposer has tried *seems* to satisfy
these constraints.
Cost to Implementors:
None.
Cost to Users:
None.
Cost of non-adoption:
Continuing confusion as to what is stable in EQ/EQL tables, and what
is stable in EQUAL tables. Possible confusion when it comes to
implementing EQUALP tables.
Performance impact:
N.A.
Benefits:
See Cost of non-adoption.
Esthetics:
The proposal more closely relates the term "Hash Table" to the
classic use of it in "The Art of Computer Programming", vol 3.
Discussion:
One of the attractions to Common Lisp is that many common techniques are
a required part of the language; C programmers who continue to re-invent
hasing techniques over and over have praised CL in particular for hash
tables. After all, it is much more likely that efficient, correctly
coded algorithms will be provided by the system supplier than that every
code writer will understand and correctly apply the information found
in Knuth's "The Art of Computer Programming", vol 3.
The requirement that the expected number of reprobes be bounded by a
"small constant" should not be taken to extreme. In particular, a
simple trade-off of space for time can assure some compliance with it.
For example, a data set of size N could be partitioned into N/20
subsets; as long as the partitioning function does a fairly good job
of balancing the number of elements in each partition class, and as
long as the partition function can be quickly calculated, then the one
could say that the expected number of probes would be bounded by "about
twenty or so". The generally understood meanings of the :rehash-size
and :rehash-threshold components of hash-tables may be biased towards
an "open-addressing" implementation; but "bucketizing" implementations
are not arbitrarily ruled out. This proposal is in no way intended to
rule out "bucketizing" implementations of hash tables.
Here's an example of how one might analyze the problems relating GC
and EQ/EQL type tables:
Date: Mon, 12 Sep 88 11:05 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: MAKE-HASH-TABLE :TEST arg
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: common-lisp@sail.stanford.edu
. . .
Various aspects of the behavior of a hash table are dependent upon the
TEST argument. An EQUAL hash table need not be rehashed after a copying
GC. The hash function is generally dependent upon the test function;
for an EQUAL hash table it would be SXHASH, while for an EQ hash table
it would probably be a simple hash on the address.
I suppose you COULD use SXHASH for all hash tables, since EQ objects are
necessarily EQUAL, and you COULD rehash ALL hash tables. Or you could
implement hash tables without actually hashing (e.g. implement them as
alists). But if performance is an issue (which it generally is when you
use a hash table), you'll probably want to do things dependent on the
test function.
barmar
This suggestion is not prohibited by CLtL, although it violates the
commonly accepted understanding of what "Hash on EQ" means.
!
----- Additional Comments -----
"This proposal is so long that I got lost while reading it. From the
examples, one would think it was proposing some rules about what users
can expect when they modify objects that are used as keys of hash
tables. However, I couldn't find anything actually proposed about that.
Most of the proposal seems to be about what performance users of hash
tables should expect, but I didn't see anything specific enough that I
could write a Common Lisp program to test whether an implementation
conforms to the proposal.
I think this proposal needs to be shortened and rewritten. I would
prefer to see it speak about the behavior a user can or cannot expect
from a Common Lisp implementation, rather than in terms of internal
details of how Common Lisp might be implemented. The essay on
implementation techniques could go in the discussion section, or could
be published separately, but I don't think it is suitable as a language
specification.
It might be a good idea to break this into two proposals, one on key
modification and a separate one on performance. The reason I say that
is that I think standardizing performance is extremely difficult, and I
would hate to see the problems with that sink the other proposal."
∂12-Dec-88 1400 X3J13-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:00:15 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 13:38:46 PST
Date: 12 Dec 88 13:34 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-133846-5027@Xerox>
A number of comments on this version are excerpted
in a section "Additional Comments" at the end.
!
Issue: MAKE-PACKAGE-USE-DEFAULT
References: MAKE-PACKAGE, CLtL p183
"USER" package, CLtL p181
Related issues: PACKAGE-CLUTTER
Category: CHANGE
Edit history: JonL White, 6-Oct-88 (version 1)
Masinter, 8-Oct-88 (version 2)
Problem description:
The proposal in the issue PACKAGE-CLUTTER would specify that
implementation-specific extensions are not in the LISP package.
With that restriction, access to implementation-specific features
is awkward; it is necessary to always name the vendor-specific
extensions in the :USE list of MAKE-PACKAGE or (if the proposal
in DEFPACKAGE is adopted) in DEFPACKAGE.
This forces users of a specific implementation to always have
to type something to get the default set of features for that
implementation, even if they have no intention of writing portable
code.
Proposal MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Change the specification of MAKE-PACKAGE (and DEFPACKAGE, if
adopted, and IN-PACKAGE, if IN-PACKAGE-FUNCTIONALITY is not
adopted) so that the default for the :USE keyword is
implementation-dependent. Normally, the default will include
the packages containing the implementation-specific features.
Portable programs should instead always specify :USE '("LISP")
explicitly.
Examples:
(package-use-list (make-package "SOME-USER"))
(package-use-list "USER")
Test Cases:
(assert
(subsetp `(,(find-package "LISP"))
(package-use-list (or (find-package "SOME-USER")
(make-package "SOME-USER")))))
Rationale:
Every implementation either already does the equivalent of this, or
else has a confusing assymetry about the USER package (i.e., their
extensions are "available" in USER, but not in SOME-USER).
Current practice:
TI and Lucid's 3.0 versions "implement" this proposal in that they set
the default :USE argument to be a list of the LISP package and the
implementation-specific package.
In VAXLISP the LISP package is the implementation-specific
package, which contains the 775 symbols supposed to be in the LISP packge
along with all the extensions; the package named COMMON-LISP
has only the 775. Thus this implements the proposal in the sense that
the inheritance of a package made with a default :USE list contains
all the implementation-specific symbols -- not just the 775 "LISP" ones.
Symbolics release 7, and Lucid's 2.1 release use only '("LISP") for the
default MAKE-PACKAGE use list, but have the aforementioned assymetry
about the USER package.
Cost to Implementors:
None; this relaxes a constraint imposed by CLtL.
Cost to Users:
In theory, every user porting code from one vendor to another would
have to ensure that every package definition, via IN-PACKAGE or
MAKE-PACKAGE, had an explicit :USE list. This is probably at most
a 5-minute text editor search. But in fact this imposition is moot,
since virtually every such user has *already* supplied explicit
:USE lists; given the current practice, he has had no alternative.
Cost of non-adoption:
There will continue to be a lack of clear standardization in this area,
especially since vendors are more willing to violate this apparently
unuseful mandate from CLtL than they are to give up a minor bias towards
their customer base.
Performance impact:
None.
Benefits:
This new default behaviour for package creation will permit
documented extensions to appear on equal footing with the basic facilities
in the LISP package. It appears as though the _majority_ of any
users are developing and running their code totally within the
enviornment provided by that one vendor; hence it seems reasonable for
implementations to bias their default use list towards those making
frequent use of their specific extensions to Common Lisp.
Esthetics:
Some feel that fewer implementation-dependent loopholes in the language
is preferable, even when the practical import is virtually moot.
Discussion:
Lucid "exposes" the default :use list as the value of the special
variable *DEFAULT-MAKE-PACKAGE-USE-LIST*, so that at site-configuration
time, one could do
(setq *DEFAULT-MAKE-PACKAGE-USE-LIST* '("LISP"))
to return to the 1984 CLtL behaviour. [This is not being proposed
at this time.]
----- Additional Comments -----
" I don't like this proposal, but I made a note to myself about another
reason that just occurred to me: There is no syntax for getting the default
(ie, system-dependent) package included if you want to -also- use some other
package."
- - - - - -
"MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT is okay with me.
I think it might be better to strengthen it and say that the
default for :USE is identical to the use list of the USER package.
Does anyone agree?
In response to Kent's remarks, the issue is whether the default should
be a portable way to get the local extensions, or a portable way to
get the portable language without the extensions. I think either of
those choices is portable and reasonable, it just depends on what you
want to make easier, which probably depends on whether a package is
being set up for use only by a predefined program or for use by user
typein and/or user-written programs, either of which are likely to
expect the local extensions.
Hence I would also accept a proposal to make the default for :USE
continue to be the LISP package, rather than incompatibly changing it,
and add a portable name for the local extensions."
- - - - - -
"re: I think it might be better to strengthen it and say that the
default for :USE is identical to the use list of the USER package.
Does anyone agree?
I agree, sort of. Especially since one of the motivating factors for
this proposal was that some Lucid 2.1 user's were complaining that
"things" look a lot different from the USER package than from a
user-created package.
The only question is whether or not you really want the default to be
sensitive to subsequent alterations of USER's :use list. As mentioned
in the Discussion section of the proposal, Lucid's implementation
exposes the default as the value of a global variable, which happens
to be a copy of the initial :use list of USER; but subsequent changes
to USER have no affect on this global variable."
- - - - - -
"The point: non-portable programs should declare that intent up-front.
This is a virtue of the current situation: if the program uses a
non-portable package, they have to state that at the head of the file. Us
poor losers who try to load it into the wrong environment get a error
before we've gotten on with the load."
∂12-Dec-88 1400 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:00:29 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 13:45:36 PST
Date: 12 Dec 88 13:44 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: PACKAGE-CLUTTER (Version 6)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-134536-5049@Xerox>
!
Issue: PACKAGE-CLUTTER
References: LISP, USER, SYSTEM packages (p181)
Related issues: LISP-SYMBOL-REDEFINITION, DEFPACKAGE,
MAKE-PACKAGE-USE-DEFAULT, IN-PACKAGE-FUNCTIONALITY
Category: CHANGE/CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
5-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter (response to KMP)
8-Dec-88, Version 5 by Masinter
(add property lists)
12-Dec-88, Version 6 by Masinter (respond to comments)
Problem Description:
CLtL specifies that
``The package named LISP contains the primitives of
the Common Lisp system. Its external symbols include
all of the user-visible functions and global variables
that are present in the Common Lisp system, such as
CAR, CDR, *PACKAGE*, etc. Almost all other packages will
want to use LISP so that these symbosl will be accessible
without qualification.''
It specifies "all" but not "all and only".
Some implementations place their extensions in the Lisp package.
Nothing in CLtL explicitly prohibits this, but it leads to problems
in general. For example:
- A user defining a function by a name not mentioned in CLtL may be
surprised to clobber a system function in some implementations
- In one particular implementation, the variable HELP was a system
constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.")
signalled a correctable error (asking what variable to bind
instead of HELP :-).
Proposal (PACKAGE-CLUTTER:REDUCE):
Specify that, not only must the LISP package contain at least all of the
symbols listed in the standard, it will have no other external symbols.
(The LISP package may have additional internal symbols.)
External symbols of the LISP package may have function, macro, or
special form definitions, top level value or SPECIAL proclamations,
or type definitions only if explicitly permitted in the specification.
That is, a program is valid Common Lisp if it assumes that
this is true; for example, FBOUNDP will be false for all
external symbols of the LISP package except those documented
to be functions, macros or special forms; BOUNDP will be false
for all those except those documented to be variables,
and portable programs can use symbols in the LISP package
as local lexical variables with the presumption that the variables
are not proclaimed special, except for those variables specified
as constants or variables.
A valid implimentation may have or put additional properties
on symbols (even user created symbols) as long as the
property indicators are not in the LISP, KEYWORD or USER
package.
This proposal constrains implementations as to what their
initial package configuration must be. That is, valid programs
can assume that the conformal Lisp implementation will not
have prohibited properties. The proposal LISP-SYMBOL-REDEFINITION
addresses the converse; that is, what user programs are allowed
to do.
Eliminate the requirement that the initial Common Lisp system
have a package named "SYSTEM". Specify that implementations may
have several other packages available, that these should be
documented. If it is appropriate, the standard might contain
as an example that implementations might have a package named
"SYSTEM".
Clarify that the "USER" package may have additional symbols interned
within it and that it may :USE other implementation-specific packages.
Examples:
#1: The symbol HELP may not be on the LISP package because it is not
mentioned in CLtL.
#2: The symbol VARIABLE is specified to be on the LISP package (because
it is a valid second argument to the DOCUMENTATION function). Since
it is not defined as a variable, type, or function, however, it will
not initially be bound, defined as a type, or defined as a function,
macro or special form.
Rationale:
If extra symbols are permitted in the LISP package, users may be surprised
by relationships between the LISP package and other packages which they
did not expect, or may be surprised by functionality that they did not
expect. The degenerate case is:
(DEFCONSTANT LISP:A 'YOU-LOSE)
(DEFCONSTANT LISP:B 'YOU-LOSE)
(DEFCONSTANT LISP:C 'YOU-LOSE)
...
(DEFCONSTANT LISP:AA 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
...etc.
Given such an implementation, even things like (LAMBDA (X) X) are not
valid because they attempt to bind "system constants". It is necessary
that the programmer be able to know for sure that an arbitrary name is
"free for use" and best way to conveniently assure this is to require
that the LISP package be unadulterated.
As for the additional definitions, there are situations where additional
definitions would cause a problem. For example, if a symbol on the Lisp
package were declared as a special variable even though that value was
not mentioned in the standard, that variable would behave incorrectly when
used as a lexical variable. Similarly, if a symbol in the lisp package
were defined as an implementation-dependent special form, problems might
result if a user redefined or even bound (as by FLET or MACROLET) that
name.
The LISP package is the foothold from which portable programs establish
their desired environment. Careful control is desirable to make sure
everyone is starting off on the right foot.
Current Practice:
Some implementations have been known to add additional symbols (usually
functional and/or variable extensions) to the LISP package.
Several implementations have restricted the LISP package to only contain
those symbols in CLtL. (The exact set was difficult to extract because not all
LISP package symbols appeared in the index of CLtL.)
Even in those implementations that have only the prescribed symbols in CLtL,
there can be extra definitions for those symbols. For example, in Symbolics Genera,
the symbols EVALHOOK, ROOM, and APPLYHOOK
are spuriously defined as special variables, and the symbol LAMBDA is defined
as a macro.
Performance Impact:
None
Cost to Implementors:
The actual cost of moving the symbols out of the LISP package in cases
where they are not already gone is quite small. However, if any
implementation really has to do this, it may have a number of suppositions
about what is in what package, and the changes could potentially be extensive.
Cost to Users:
This change is upward compatible with any portable program, but users
of a particular implementation's extensions may be forced to find their
functions in a different package, so there may be a measurable practical
cost.
In many cases where an extension symbol FOO is simply expected to have
been directly available (due to :USE "LISP"), it will work to just just
do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is
declared.
More likely the extension symbols would be moved to one or more
extensions packages, e.g. ACME-COMMON-LISP, so user packages in which
the extensions were desired could simply :USE the extensions package(s).
Implementations might want to use this way of conforming with this
proposal in order to minimize cost to users.
In many cases where an extension symbol FOO is used by explicit package
prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or
even `LISP:' to find the cases.
Cost of Non-Adoption:
The potential for the LISP package to be adulterated and for supposedly
portable programs to have difficulty getting a foothold in some
implementations will be `noticeably non-zero'.
Benefits:
Portability of some programs will be enhanced.
Aesthetics:
This change probably supports the naive expectation of most programmers
writing portable code.
Discussion:
This proposal basically affects what implementors are allowed to do;
it says that portable programs can rely on a standard initial package
structure with the same symbols in it. A separate proposal,
LISP-SYMBOL-REDEFINITION, discusses the restrictions on portable
programs as far as redefining LISP symbols.
Whether the USER package may contain symbols other than those
specified in the standard was controversial. The smart programmer
of portable code will never rely on the contents of the
USER package. However, if someone wants a completely empty
package that uses only Lisp, it's easy and portable to create one.
While it would improve portability slightly to disallow additional internal
symbols in the LISP package (since it affects what DO-SYMBOLS will do)
explicitly prohibiting a common practice didn't seem like the best way
to discourage a possibly troublesome implementation technique.
Implementors should be especially careful about accidentally
exporting unwanted additional definitions for symbols,e.g., a variable
definition for EVALHOOK which might show through because of
an unintended name collision.
It is likely that the recently included portions of the standard (CLOS and
the signal mechanism) will reside in their own packages. These externally
defined packages should have the same constraints as outlined for
the LISP package here.
There has been a suggestion that vendor-specific extensions should
be placed in a package named like ACME-COMMON-LISP for the "Acme"
company.
A registry of packages (as well as features, modules and other global
names) would be useful, although probably not a part of the language
standard, per se.
----- End Forwarded Messages -----
∂12-Dec-88 1434 X3J13-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:27:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 14:26:26 PST
Date: 12 Dec 88 14:26 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 6)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-142626-5215@Xerox>
This issue has consumed a large number of "cleanup" committee
cycles. (I have over 80 messages filed on this one topic.)
We hope to have another proposal available as a possible
resolution of the same issue...
!
Issue: REQUIRE-PATHNAME-DEFAULTS
References: *MODULES*, PROVIDE, REQUIRE, pp 188-191
LOAD, pp 426-427
Category: CHANGE
Edit history: Version 1 by Pierson 9/13/88
Version 2 by Pierson 9/19/88, change PROVIDE stuff per comments
Version 3 by Pierson 10/17/88, remove PROVIDE locaction specs.
Version 4 by Pierson 10/31/88, remove from language
Version 5 by Pierson 11/15/88, cleanup, fix discussion
Version 6 by Pierson 12/9/88, remove *MODULES* as well
Problem description:
PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences. These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.
Proposal (REQUIRE-PATHNAME-DEFAULTS:ELIMINATE):
Remove PROVIDE, REQUIRE, and *MODULES* from the Common Lisp standard.
Test Cases/Examples:
(PROVIDE 'fft)
Would not be Common Lisp.
(REQUIRE 'fft)
Would not be Common Lisp.
Rationale:
The file loading feature of REQUIRE is non-portable. The remaining
functionality of PROVIDE and REQUIRE (pushing and testing *MODULES*)
can easily be implemented by user code. Since some implementations
will retain the automatic module loading features of REQUIRE and some
won't, use of REQUIRE will almost always make code less portable.
Current practice:
All implementations currently support some sort of file loading via
single-argument REQUIRE. In general, the Lisp Machine implementations
invoke the system module building/loading facility while the Unix
implementations simply try to load a file in the current directory.
Cost to Implementors:
Implementations will have to move PROVIDE and REQUIRE to their package
for implementation extensions and change their documentation to
indicate that PROVIDE and REQUIRE are non-standard. This is a fairly
small change.
Cost to Users:
Non-portable programs that rely on PROVIDE and REQUIRE will probably
be unaffected since implementations will probably maintain their
existing functionality. Since the current behavior is decidedly
non-portable, portable programs have to aviod or special-case PROVIDE
and REQUIRE anyway.
Cost of non-Adoption:
PROVIDE and REQUIRE will continue as impediments to portability.
Benefits:
The non-portability of PROVIDE and REQUIRE will be made obvious.
Aesthetics:
This simplifies the language by removing an environment-dependent
feature.
Discussion:
The cleanup committee tried to come up with a proposal to restrict
PROVIDE and REQUIRE to the portable subset of their functionality.
This failed because several implementors objected that it compelled
them to significantly reduce the functionality they provided users in
order to create a trivial feature which any user could easily write
for herself.
Fahlman, Gregor, Grey, Loosemore, Moon, Pierson, Pitman, Steele, and
Zacharias have expressed support for removing PROVIDE and REQUIRE from
the language, at least as the lesser of several evils.
JonL would much rather see PROVIDE and REQUIRE remain in the language
as a safety net behind any implementation-specific system building
facility. Pierson likes the safety net idea, but doesn't think it's
workable without forbidding REQUIRE from loading files.
Pitman suggested that PROVIDE and REQUIRE should be depricated rather
than removed entirely. Pierson agrees, but notes that Larry wants us
to deal with deprication versus elimination as a separate global topic.
Several people have expressed a desire not to break existing user
code. If accepted, this proposal should not break existing code
because all implementations are expected to retain their current
PROVIDE and REQUIRE functionality as an extension to Common Lisp.
∂12-Dec-88 1434 X3J13-mailer Issue: PROCLAIM-LEXICAL (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:27:29 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 14:10:50 PST
Date: 12 Dec 88 14:08 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: PROCLAIM-LEXICAL (Version 9)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-141050-5132@Xerox>
!
Issue: PROCLAIM-LEXICAL
References: variables (p55), scope/extent (p37), global variables (p68),
declaration specifiers (p157)
Category: CLARIFICATION/ADDITION
Edit history: Version 2 by Rees 28-Apr-87
Version 3 by Moon 16-May-87
Version 4 by Masinter 27-Oct-87
Version 5 by Masinter 14-Nov-87
Version 6 by Pitman 15-Sep-88
(major revision, for review by Jonathan Rees and Jeff Dalton)
Version 7 by Pitman 24-Sep-88
(minor revisions based on comments from Rees and Dalton)
Version 8 by Pitman 06-Oct-88 (merge recent discussion)
Version 9 by Masinter 8-Dec-88 (make JonL's changes)
Problem Description:
Although local variables in Common Lisp may be `special' or `lexical,'
global variables (with the exception of named constants) may currently
only be `special.'
The Scheme language permits free variable references to refer to global
bindings. Their experience suggests that such usage would be useful to
the Common Lisp community. The absence of such a facility in Common Lisp
is a barrier both culturally (to the sharing of ideas) and technically
(to the sharing of code).
SPECIAL proclamations are uncontrollably pervasive. There is no way
to locally override or globally undo a SPECIAL proclamation.
Background/Analysis:
Variable evaluation may be viewed in Common Lisp as a search through
a set of environments to find a binding, and then the dereferencing of
that binding. The environments with which Common Lisp deals are
Lexical (L), Dynamic (D), and Global (G).
A SPECIAL declaration for a variable amounts to a request that the
variable be resolved by searching first the Dynamic and then the Global
environment (DG).
As currently described in CLtL, lexical variable reference searches
only the Lexical environment (L).
Because undeclared free variables in the interpreter are implicitly
declared SPECIAL by most (perhaps all) implementations, this amounts
to a search of Lexical, Dynamic, and Global (LDG). However, the
accompanying warnings in many implementations make it clear that this
behavior is not intended to be taken seriously.
Constants are looked up solely in the Global environment (G). They
have other properties as well, of course.
In the Scheme language, the default lookup is first Lexical, then
Global (LG). Providing compatibility for Scheme code is, and more
generally for a Scheme working style is therefore difficult because
Common Lisp does not provide the LG search style.
The issue of whether a variable can be assigned is orthogonal.
The issue of whether a variable can be bound and, if it can be, which
environment is used for the new binding is orthogonal.
Proposal (PROCLAIM-LEXICAL:LG):
Provide a new declaration (and proclamation) called LEXICAL which implies
LG lookup. That is, variables declared LEXICAL would be looked up first
in the lexical environment (L) and then in the global environment (G)
if not found in the lexical.
Clarify that a dynamic binding of a variable creates a new binding
in the dynamic environment (D) leaving the global environment (G)
unaffected.
Clarify that special variable access does DG lookup. That is,
variables declared SPECIAL would be looked up first in the dynamic
environment (D) and then in the global environment (G) if not found
in the dynamic one. Further clarify that SYMBOL-VALUE does DG lookup.
Define that a lexical binding of a variable creates a new binding
in the lexical environment (L), leaving the global environment (G)
and the dynamic environment (D) unaffected.
Note that an assignment to a variable which is bound in the global
environment (G) will affect lexical (LG) lookups for which there is
no lexical (L) binding and dynamic (DG) lookups for which there is
no dynamic (D) binding.
Note that these restrictions describe an abstract model, not a
concrete implementation. An implementation may still choose to
implement dynamic binding as either deep or shallow, but some
searching may be necessary to find the global cell in shallow bound
implementations [unless dynamic binding has been forbidden for
that variable].
Like SPECIAL declarations (and unlike type declarations),
compilers and interpreters would be required to notice and
respect LEXICAL declarations.
Examples:
#1: (proclaim '(lexical x))
(setq x 1)
(defun f (fn) (list x (funcall fn)))
(defun g (fn)
(let ((x 2))
(declare (special x))
(funcall fn #'(lambda () x))))
(g #'f) => (1 2)
#2: ; Warning: It is unlikely that any serious program would
; be written in so obscure a manner as this example.
; This just tests the fringe cases.
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
If the results of this example confuse you, keep in mind
that the results of code like this would be somewhat
confusing no matter what the chosen semantics because the
code itself is far from perspicuous.
An explanation of this behavior, which some people find less
than intuitive because of the bizarre choice of constructs:
X gets bound lexically to 3 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 4 because Y is [pervasively]
proclaimed SPECIAL.
Reference style for name X is changed to SPECIAL, making
lexical X=3 invisible.
Reference style for name Y is changed to LEXICAL, making
dynamic Y=4 invisible.
Global X=1 and global Y=2 are first two elements of list.
X gets bound lexically to 5 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 6 because Y is [pervasively]
proclaimed SPECIAL.
Closure is returned, capturing [lexical] X=5 but not
[special] Y=6.
Dynamic binding of Y to 6 disappears, dynamic binding
of Y to 4 reverts.
Closure is funcalled, returning captured X=5 and dynamically
active Y=4 in a list which becomes third list element.
Rationale:
This mechanism provides a simple and straightforward answer to
the problems stated above.
Current Practice:
Probably no one implements this.
Cost to Implementors:
A fair amount compiler work would probably be needed. Some compilers
may have hooks for most of this already laying around, but some may not.
Note well that this proposal does not require separate global lexical
and dynamic cells, so the data storage layout of Lisp need not change.
Moon says...
I have now thought of an efficient way to do this on Lisp machines,
using invisible pointers, and another efficient way to do it on
stock hardware, using one extra instruction on every global
reference of one or the other sort, plus a few extra instructions
in SPECIAL binding and unbinding. Given that, I no longer object
to the proposal as unimplementable.
It doesn't just require a few compiler changes, it requires some
reimplementation of the representation of global variables, with
concomitant changes to the compiler, the loader, the interpreter,
and probably the debugger. Every symbol now potentially has two
values accessible from the interpreter (the current SPECIAL and
the global LEXICAL) and you need the corresponding new data
structure to keep track of that.
Rees suggests...
In shallow-bound implementations, implementors may have to add a
small run-time routine that searches the dynamic saved-binding
stack to look for the global value in the case where the variable
has been dynamically bound. One might want a bit (or a count)
somewhere (perhaps in the symbol itself) to speed up the common
case of access to a global binding of a variable that hasn't been
dynamically bound; without some kind of optimization, you have to
search the whole saved-binding stack on every reference to a
free [lexical] variable.
While naively you might think you'd incur the cost of clearing the
valid bit on every dynamic binding (not acceptable), in actuality
the bit is a static property of programs (PROGV excepted). So the
only places you ever need to clear FOO's valid bit are in PROGV,
in the interpreter, and when FASLOADing code that contains a compiled
dynamic binding of FOO.
Cost to Users:
For the most part, this change is upward compatible.
Some code-walking tools would have to change.
Cost of Non-Adoption:
It would continue to be difficult to share code with Scheme.
New CL users coming from the Scheme community would be confused by
their sometimes inability to map what they know about variable binding
into the CL model of variable binding.
Some interesting native CL applications would be impossible to write
in a syntactically convenient style.
Benefits:
Enhanced flexibility of expression.
Rationalization of the semantics of dynamic variables.
Aesthetics:
Improved appeal to a certain sector of the programming community.
Discussion:
Rees points that it is an oversimplification to describe Scheme's
binding simply as LG since they have no Dynamic environment and
there is no way to distinguish LG and LDG. However, the reasons he
prefers LG are:
1. It's nice for readability and understandability to have a
declaration which tells you that a variable will not be
dynamically bound.
2. It's nice for performance in deep-bound implementations to have a
declaration that says that no search will be needed.
Of course, he notes, there could be a counter-argument to item 2
(in favor of LDG) in order to prefer shallow bound implementations,
but that still would not defeat the argument in item 1. Rees believes
that LG is slightly preferrable, but that LDG would be essentially
adequate for most of his needs.
Pitman supports PROCLAIM-LEXICAL:LG and believes that giving LDG the
name LEXICAL would be a serious mistake, leaving open the door for
program bugs due to accidental binding of variables presumed by the
programmer not to be bound. If someone (Moon?) seriously wanted LDG
type variables in addition to LG variables (under a name other than
LEXICAL), Pitman would not object.
Dalton expressed support for PROCLAIM-LEXICAL:LG (Version 6).
He observes that another reason for opposing LDG is that it suggests
the possibility that someone might want DLG. LG is simpler and still
accomplishes the stated purpose. He adds ``I would like to be able
to explain the global environment as a sort of giant, extensible
LET abound everything. This proposal seems to get fairly close.''
It would be possible to submit a proposal for a GLOBAL (G) declaration
under separate cover if anyone (Xerox?) was interested. Pitman thinks
this would be an interesting idea. Dalton points out, however, that
already with this proposal there is enough power to at least deal with
globals -- albeit circuitously. For example, to reference a global
variable X, one could write subroutines such as:
(defun global-x () (declare (lexical x)) x)
(defun set-global-x (value) (declare (lexical x)) (setq x value))
Eg, consider:
(defun f (x) (+ (global-x) x))
In principle, we could imaging saying that free variables should be
lexical by default, but that would only reduce error checking to no
good end. To be really useful, this proposal will need to be followed
by a proposal for primitives analogous to DEFVAR and/or DEFPARAMETER
but for lexical variables. However, since arguments over syntax are
likely to have plenty of issues of their own, we've separated this
proposal for primitive functionality from issues of syntax which
can be dealt with separately once this is passed.
Moon expressed concerns about the efficiency issues but after
thinking about it for a while convinced himself that this is
efficiently implementable both on stock and special purpose hardware.
JonL expressed concerns about the last-minute nature of this change,
which he sees as untested. This concern applies to the mixin of
the dynamic environment implicit in the LDG proposal.
Dalton suggests that an alternative solution to the speed issue
might be possible to obtain by restricting a particular variable to
be either LEXICAL or SPECIAL but not both.
Dalton points that even if people don't like the details here, there
must be a better fallback solution than "do nothing". Pitman agrees
heartily.
∂12-Dec-88 1528 X3J13-mailer Issue: TAILP-NIL (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 15:27:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 15:18:20 PST
Date: 12 Dec 88 15:17 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TAILP-NIL (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-151820-5387@Xerox>
!
Issue: TAILP-NIL
References: TAILP (p275)
Category: CLARIFICATION/CHANGE
Edit History: 13-Sep-88, version 1 by Walter van Roggen,
13-Sep-88, version 2 by Pitman
18-Oct-88, version 3 by van Roggen (just one proposal)
01-Dec-88, version 4 by Pitman (minor edits per discussion)
9-Dec-88, Version 5 by Masinter (clarify EQL)
Problem Description:
CLtL (p275) specifies TAILP as:
TAILP sublist list [Function]
This predicate is true if SUBLIST is a sublist of LIST (i.e.,
one of the conses that makes up LIST); otherwise, it is false.
Another way to look at this is that TAILP is true if
(NTHCDR n list) is SUBLIST, for some value of N. See LDIFF.
Two implementations of this definition might be:
(defun tailp (sublist list) ;Definition "A"
(do ((list list (cdr list)))
((endp list) nil)
(if (eql sublist list)
(return t))))
(defun tailp (sublist list) ;Definition "B"
(do ((list list (cdr list)))
((atom list) (eql list sublist))
(if (eql sublist list)
(return t))))
They differ only in their treatment of the atomic case.
At issue is the fact that () is a list, and hence some would
argue that it is a sublist of all other lists. On the other hand,
the definition of TAILP seems to imply that being a cons is a
necessary precondition of being a "sublist".
Also at issue is the question of whether dotted lists are permissible
second arguments.
Proposal (TAILP-NIL:T):
Strike any text in the definition of TAILP which suggests that a
sublist must be a cons.
Clarify that (TAILP sublist list) returns true iff (NTHCDR n list) is
sublist for some value of n, and false otherwise.
Note, however, that since the list may be dotted, so the end test
used by TAILP must be ATOM, not ENDP. That is, if (TAILP x l)
returns true, it means there was n such that (NTHCDR n list) would
return x; however, it doesn't follow that if TAILP returns false,
it is safe to go blithely NTHCDR's into the list looking for it,
since the list might be dotted and NTHCDR might hit bad data.
Note that TAILP uses EQL or equivalent to compare
sublist to list in the case where sublist is a number, etc.
Rationale:
This is more consistent with the definition of LDIFF, which
gives a useful meaning to arbitrary atomic SUBLIST arguments.
This gives a more elegant definition of SUBLIST, allowing it to
refer to any list -- including the empty list -- which is a
part of another list.
Some reasons for preferring an ATOM check to ENDP include:
- The name TAILP suggests tails, not sublists. Some users might
expect this distinction to mean that data more general than
proper sublists.
- Making TAILP require lists limits its usefulness. If we did
not make this choice, some users would end up having to write
their own extended TAILP which we could just as well have
provided compatibly.
- TAILP is not considered to be used frequently enough in code
that the minor loss in speed to an ATOM check is worth the
lost functionality. Indeed, expanding the scope of its
capabilities may lead to more uses for TAILP.
- Other operators (eg, APPEND) have recently been extended to
treat dotted lists in an interesting way because users have
expressed a desire for this. As such, this change is
culturally consistent.
- Some implementations already support this feature, and the
wording in CLtL is sufficiently ambiguous that some users
might think it appropriate to depend on the feature. In the
absence of compelling efficiency reasons to the contrary,
we should lean toward extending some implementations rather
than tightening others in our efforts to achieve cross-dialect
consistency.
Examples:
#1: (LET ((X '(B C))) (TAILP X (CONS 'A X)))
should return T in all implementations.
#2: (TAILP '(X Y) '(A B C))
should return NIL in all implementations.
#3: (TAILP '() '(A B C))
returns T under this proposal.
#4: (TAILP 3 '(A B C))
returns NIL under this proposal.
#5: (TAILP 3 '(A B C . 3))
returns T under this proposal.
#6: (TAILP '(X Y) '(A B C . 3))
returns NIL under this proposal.
Current Practice:
Symbolics Genera is consistent with TAILP-NIL:T.
Neither Lucid nor VAX LISP currently implements TAILP-NIL:T.
VAX LISP effectively implements definition "A" from the
Problem Description above.
Cost to Implementors:
An implementation of TAILP-NIL:T is given as Definition "B" in the
problem description.
Some implementations might have compiler optimizers for these definitions
as well, so a slight amount of additional effort might be required.
Cost to Users:
Given that current practice varies widely on the disputed case,
this is unlikely to have a practical effect on existing portable code.
Benefits:
Avoids unnecessary incompatibilities between implementations.
Non-Benefits:
Slows down TAILP slightly in some implementations because ENDP is
potentially faster than ATOM.
Discussion:
This issue was first raised in ">GLS>clarifications.text" of 12/06/85.
It recommended an earlier proposal, TAILP-NIL:NIL, which is effectively
equivalent to Definition "A" from the Problem Description.
Pitman introduced TAILP-NIL:T as an alternative, arguing that the
definition TAILP-NIL:NIL offered no practical value to programmers
in the disputed situations, while TAILP-NIL:T was of arguable usefulness.
Pitman and van Roggen support TAILP-NIL:T.
It was suggested more than once by more than one cleanup
committee member that we remove TAILP from the language
"since almost nobody uses it".
∂12-Dec-88 1601 X3J13-mailer Re: Issue: TEST-NOT-IF-NOT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:01:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 15:55:20 PST
Date: 12 Dec 88 15:53 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TEST-NOT-IF-NOT (Version 3)
In-reply-to: my message of 9 Dec 88 15:26 PST <881209-153026-1243@Xerox>
To: X3J13@sail.stanford.edu
Message-ID: <881212-155520-5496@Xerox>
The writeup in this issue was mislabelled Version 2. In fact, it was
Version 3, 1 Dec 88, Masinter (add comments).
The ballot will reflect this.
∂12-Dec-88 1609 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:09:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 16:01:09 PST
Date: 12 Dec 88 16:00 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-160109-5511@Xerox>
As JonL pointed out, Version 2 was missing a "not" in
a key sentence in the proposal.
!
Forum: Cleanup
Issue: TYPE-OF-UNDERCONSTRAINED
References: TYPE-OF (CLtL)
88-002R (Class-of)
88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
DATA-TYPE-HIERARCHY-UNDERSPECIFIED
FUNCTION-TYPE
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
COERCE-INCOMPLETE
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 1-Dec-88, Masinter
Version 2, 9-Dec-88, Masinter
Version 3, 12-Dec-88, Masinter (fix "egregious bug")
Problem description:
The specification of TYPE-OF in CLtL is so weak as to leave it
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.
This means that implementations could return T for all other objects.
Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS):
Specify that the result of TYPE-OF satisfies the following:
(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of
INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER
SYMBOL,
STRING, VECTOR, ARRAY,
CONS,
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize.)
(b) For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)
(c) will not be a MEMBER type specifier, or T.
For objects created by the "constructor" function of a structure
defined with DEFSTRUCT without a :TYPE option, TYPE-OF
will return the structure name.
For objects created by MAKE-INSTANCE, giving a named
class, TYPE-OF will return the class name of the class.
For objects which are instances of anonymous classes (i.e., where
(CLASS-NAME (CLASS-OF object)) is NIL), the result of TYPE-OF should be the
class object itself.
(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)
This proposal is intended to be consistent with 88-002R,
and not to conflict with any of the definitions in that document.
Examples:
It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
Given:
(defvar *foo* (make-array 5 :element-type t))
(class-name (class-of *foo*)) => SIMPLE-VECTOR
It is legal for
(type-of *foo*) => (SIMPLE-VECTOR 5)
Rationale:
The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended.
Current practice:
Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.
Cost to Implementors:
Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal.
Cost to Users:
Apparently none.
Cost of non-adoption:
TYPE-OF would remain potentially inconsistent.
Performance impact:
Likely none.
Benefits:
Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.
Esthetics:
Little effect.
Discussion:
Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.
The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did.
This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.
If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass,
and this proposal does pass, it may be that the only way an
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.
It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable
implementation-specific value. For example,
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]
We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.
----- End Forwarded Messages -----
∂12-Dec-88 1623 X3J13-mailer Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:22:49 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 16:17:33 PST
Date: 12 Dec 88 16:17 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-161733-5559@Xerox>
!
Issue: UNREAD-CHAR-AFTER-PEEK-CHAR
References: pp 379, 380 of CLtL
Category: CLARIFICATION
Edit history: Version 1 by Doug Cutting <Cutting.PA@Xerox.COM> on July 29, 1988
Version 2 by Masinter 2-Dec-88
Problem description:
PEEK-CHAR and UNREAD-CHAR are very similar mechanisms. The description of
PEEK-CHAR in CLtL even states that "it is as if one had called READ-CHAR and
then UNREAD-CHAR in succession." But while CLtL prohibits calling UNREAD-CHAR
twice in succession it does not prohibit calling UNREAD-CHAR after PEEK-CHAR.
The obvious implementation of PEEK-CHAR and UNREAD-CHAR (a one-character buffer)
will not work unless this prohibition is present.
Proposal (UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW):
Rewrite the specification so that it is clear that doing either a
PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
on any character preceding that which is seen by the PEEK-CHAR (including
those passed over by PEEK-CHAR when `seeking' with a non-NIL first
argument) is not specified.
In particular, the results of calling UNREAD-CHAR after PEEK-CHAR
is unspecified.
Example:
(defun test (&optional (stream *standard-input*))
(let* ((char1a (read-char stream))
(char2a (peek-char nil stream))
(char1b (progn (unread-char char1a stream)
(read-char stream)))
(char2b (read-char stream)))
(list char1a char2a char1b char2b)))
This is not legal, since the PEEK-CHAR for char2a "commits"
the character read by char1a, and so the unread-char is not legal.
Rationale:
PEEK-CHAR and UNREAD-CHAR provide equivalent functionality and it is thus
reasonable for an implementation to implement them in terms of the same
mechanism.
Current practice:
In Xerox Common Lisp, different (non-random-access) stream types behave
differently. One, (TCP/FTP) handled this correctly, while another did not.
In Symbolics Genera, for the Example above:
(test)ab
=> (#\a #\b #\a #\b)
(with-input-from-string (s "abc") (test s))
=> (#\a #\b #\a #\b)
(progn (with-open-file (s "foo.output" :direction :output)
(write-string "abc" s))
(with-open-file (s "foo.output" :direction :input)
(test s)))
Signals an error about unreading #\a when #\b was already unread.
Cost to Implementors:
Presumably none. Implementations which allow this are still correct.
Cost to Users:
Small. I suspect there is very little code which depends upon this working
correctly, as most code uses either PEEK-CHAR or UNREAD-CHAR, but not both.
Cost of non-adoption:
Implementations of sequential streams are forced to be unnecessarily complex in
order to be correct.
Benefits:
Allows simple yet adequately powerful implementation of sequential streams.
Esthetics:
Requires that users have shared, one-char buffer model of how UNREAD-CHAR and
PEEK-CHAR work, rather than two separate one-char buffers.
Discussion:
<none>
∂12-Dec-88 1622 X3J13-mailer Issue: REST-LIST-ALLOCATION (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:22:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 16:11:10 PST
Date: 12 Dec 88 16:08 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: REST-LIST-ALLOCATION (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-161110-5531@Xerox>
Thanks to Will Clinger for getting a last minute revision in.
!
Forum: Cleanup
Issue: REST-LIST-ALLOCATION
References: CLtL pp 107-108 (APPLY)
Related issues: DYNAMIC-EXTENT
Category: CLARIFICATION
Edit history: 8-Dec-88, Version 1 by Masinter
9-Dec-88, Version 2 by Clinger (add rationale, more discussion)
12-Dec-88, Version 3 by Clinger (delete bogus examples)
Problem description:
In the special case of calling a function with an &REST list via APPLY,
Common Lisp fails to specify whether a new copy of the list is freshly
allocated. For example, given
(DEFVAR *MY-LIST* '(A B C))
(DEFUN FOO (&REST X) (EQ X *MY-LIST*))
does
(APPLY #'FOO *MY-LIST*)
return T?
This issue is different from the question of the extent of "rest lists" in
the case when they *are* newly allocated which is indefinite; the issue
DYNAMIC-EXTENT also contains some proposals about extent.
Proposal (REST-LIST-ALLOCATION:NEWLY-ALLOCATED):
Specify that &REST lists are newly allocated in the case when the function
is called via APPLY.
Proposal (REST-LIST-ALLOCATION:MAY-SHARE):
Specify that the value of an &REST parameter is permitted, but not required,
to share (top-level) structure with the last argument to APPLY.
Proposal (REST-LIST-ALLOCATION:MUST-SHARE)
Specify that the value of an &REST parameter is required
to share (top-level) structure with the last argument to APPLY.
>> this needs better spec about how the args match <<
Examples:
(DEFVAR *MY-LIST* '(A B C))
(DEFUN FOO (&REST X) (EQ X *MY-LIST*))
(APPLY #'FOO *MY-LIST*) => T ;on Symbolics systems and probably
; many stock hardware implementations
This implies that
(DEFUN BAR (&REST X) (RPLACA X 'D))
(APPLY #'BAR *MY-LIST*)
*MY-LIST* => (D B C) ;on Symbolics systems and probably many stock
; hardware implementations
Another example: which of the following have the same semantics?
(setq x '(1 2 3))
[1] (apply #'foo 1 2 3 NIL)
[2] (apply #'foo 1 2 (cddr x))
[3] (apply #'foo 1 (cdr x))
[4] (apply #'foo x)
[5] (funcall #'foo 1 2 3)
Under REST-LIST-ALLOCATION:NEWLY-ALLOCATED:
[1]-[5] are equivalent.
Under REST-LIST-ALLOCATION:MAY-SHARE:
Any answer to the question is correct for some conceivable implementation.
Abstracting over implementations, this means that [1]-[5] are pairwise
non-equivalent.
Under REST-LIST-ALLOCATION:MUST-SHARE:
[1]-[4] are pairwise non-equivalent in all implementations. This proposal
leaves open the question of whether [1] is equivalent to [5].
And finally:
Should (defun foo (&rest x) ...)
behave (aside from efficiency) as if it were defined:
(defun foo (&rest G0047) ;Gensym really
(let ((x (copy-list G0047)))
...))
Rationale:
The semantics of APPLY is unclear. In consequence it is impossible
to write portable code that relies on &REST arguments sharing structure
with the last argument to APPLY. Portable code can rely on &REST arguments
*not* sharing structure with the last argument to APPLY, but only by
performing an explicit COPY-LIST on all &REST arguments; this is redundant
and inefficient in implementations where &REST arguments are newly
allocated anyway.
Current practice:
Some implementations always share. Some implementations never share.
A few may share interpreted and not share compiled, or vice versa.
Cost to Implementors:
None for MAY-SHARE, since that is the status quo. Both of the other
proposals entail a significant cost for some implementations.
If MUST-SHARE is adopted, then implementations that don't share structure
may be nearly impossible to convert. If NEWLY-ALLOCATED is adopted, then
implementations that do share will have to insert a call to COPY-LIST
inside either APPLY or &REST list handling, which will slow things down
and may be difficult as well.
Cost to Users:
No matter what, somebody gets hurt. MAY-SHARE means you have to
write awkward and inefficient code if you care. (This is already
the case for portable code.) MUST-SHARE means you have to add
explicit calls to COPY-LIST to code that assumes the contrary.
NEWLY-ALLOCATED means you have to rewrite code that assumes sharing.
Cost of non-adoption:
Great confusion over the issue. A certain amount of awkwardness and
inefficiency would remain inevitable if you want to write portable code.
Performance impact:
MUST-SHARE costs least in consing, but might slow down function call
for some implementations. MAY-SHARE lets implementations pick, has
least impact. NEWLY-ALLOCATED requires consing in cases where it
didn't before.
Benefits:
Less confusion. Improved portability.
Esthetics:
Differing, strongly held opinions.
Discussion:
The Revised3 Report on Scheme specifies that the equivalent of a
&REST argument must be a newly allocated list, to avoid precisely this
problem.
The argument for MUST-SHARE is that copying is inefficient, so
&REST should never cause copying of a list passed to it from APPLY.
Functions that desire a new copy can just call COPY-LIST.
Two arguments for MAY-SHARE are:
1. In no other place does Common Lisp automatically unshare structure,
except when the user is explicitly modifying the structure (as in REMOVE).
Making APPLY automatically unshare would be a semantic wart.
2. If APPLY copies its last argument, recursive programs that receive an
&REST argument and pass it to APPLY become inefficient. A linear time
algorithm can change to a quadratic time algorithm. While the efficiency
could be regained through compiler flow analysis in many cases, it's
better not to put the inefficiency into the language in the first place.
The DYNAMIC-EXTENT proposal would allow &REST lists
that were "newly allocated" to have dynamic extent if they were
to be passed down via APPLY. This puts the burden in the
right place.
Two (closely related) arguments for NEWLY-ALLOCATED:
1. The programmer's model of function calling is simpler: functions
take arguments, and any two calls that pass the same arguments to the
same function are equivalent. The MAY-SHARE and MUST-SHARE proposals
require a model in which functions generally take their arguments in
the form of a list, and the extent to which that list shares structure
with other lists in the system becomes an important part of the
semantics of a function call.
2. It's not only smashing a &rest argument that's a problem, it's
smashing any list that has been given as the last argument to APPLY as
well. Consider the following in an implementation that doesn't copy
the last argument to APPLY when it is passed as a &rest argument:
> (defvar *message*)
*MESSAGE*
> (defun set-message (&rest mess)
(setq *message* mess))
SET-MESSAGE
> (let ((winner (list 'a 'winner)))
(apply #'set-message winner)
(setf (cdr winner) (list 'loser))
winner)
(A LOSER)
Is *message* (A WINNER) or (A LOSER)? (It might be
(#<DTP-LOCATIVE 76123756> #<DTP-ODD-PC 12313453> ...)
but that's a different problem.) This suggests that once a list has
been given as the last argument to APPLY it is no longer OK to modify
it.
Gail Zacharias talked about the common idiom of simply doing a COPY-LIST
on every &rest argument, to insure some normalcy. Her reasoning seems
to bolster the case for those who claim that the current CL semantics
(MAY-SHARE) are deficient:
Subject: &REST Lists
Date: 24 Mar 88 12:23:15 EST (Thu)
From: gz@spt.entity.com (Gail Zacharias)
. . .
If Common Lisp doesn't require unshared &rest lists, then I think
it must provide a declarative version of this idiom so the COPY-LIST can
be portably avoided when it's redundant. Seems to me that the fact that
this is a common case where users find a need for conditionalization
indicates a real deficiency in Common Lisp's specification.
. . .
So we have a responsibility to resolve the very thorny issue
of REST-LIST-ALLOCATION.
∂12-Dec-88 1735 X3J13-mailer CommonLisp/C interface
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 17:35:03 PST
Received: from fafnir.think.com by Think.COM; Mon, 12 Dec 88 19:47:10 EST
Return-Path: <kahle@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 12 Dec 88 20:33:03 EST
Received: from ungar.think.com by verdi.think.com; Mon, 12 Dec 88 20:31:35 EST
Received: by ungar.think.com; Mon, 12 Dec 88 20:32:57 EST
Date: Mon, 12 Dec 88 20:32:57 EST
From: kahle@Think.COM
Message-Id: <8812130132.AA13377@ungar.think.com>
To: x3j13@sail.stanford.edu
Subject: CommonLisp/C interface
We at Thinking Machines have been using Common Lisp as a system programming
language. The principle features that are missing from CommonLisp for this
purpose is the Lisp/C interface specification. This deficiency makes our
code non-portable. On the other hand, Lucid has provided a good set of
functions that have gotten better in each release. To start the
discussion:
I propose the Common Lisp committee adopt the Lucid 3.0 foreign function
interface as the Common Lisp standard.
-brewster
Brewster@think.com
∂12-Dec-88 1755 X3J13-mailer Issue: TAILP-NIL (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Dec 88 17:55:38 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 507602; Mon 12-Dec-88 20:55:04 EST
Date: Mon, 12 Dec 88 20:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)
To: x3j13@sail.stanford.edu
cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: <881212-151820-5387@Xerox>
Message-ID: <19881213015522.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Correction: Contrary to what the current practice section says,
the proposal TAILP-NIL:T is not what Symbolics Genera does. In
fact I know of no implementation that does what the proposal says.
However, I support the proposal anyway, because I think it's the
most consistent with the rest of Common Lisp.
∂12-Dec-88 1838 X3J13-mailer ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 18:38:07 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 18:16:49 PST
Date: 12 Dec 88 18:16 PST
From: masinter.pa@Xerox.COM
to: x3J13@sail.stanford.edu
Subject: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
Message-ID: <881212-181649-5908@Xerox>
The issues and proposals named below have been mailed to the X3J13 mailing
list. (Hardcopy mail will follow.)
This ballot is "for informational purposes": If there are errors, problems,
or corrections to any of the issues-- especially the late-breaking ones--
please prepare amendments or new versions to bring to the January meeting.
The purpose of the ballot is to help us avoid discussing the
non-controversial issues; the ballot will tell us which issues should be
included in a "block" vote of endorsement/rejection. There will be
opportunity at the January meeting to correct mistakes or review issues, if
there is some belief that they were incorrectly framed, misunderstood, or
should otherwise be reviewed.
For each proposal, please chose one of the following:
[Y]es: adopt the Proposal
[N]o: don't adopt the Proposal
[I]f the following condition holds....
Only adopt the proposal given some precondition
[C]larify the following point & resubmit
You don't understand the proposal (please explain)
[A]bstain
You have read & understood the proposal but don't care
about the outcome
The result of the vote will be used by the cleanup committee:
Y (if majority): we will include in a "block" resolution
N (if majority): we will not raise the issue at X3J13
I: if no "unconditional" majority, your conditions will
affect what we propose to X3j13
C: we will attempt to clarify (even if the issue gets
a majority vote.)
Our goal is that all "voters" understand all
the issues.
A: your vote will not count in the total
Who can vote?
Anyone who wants to vote may do so, whether members of X3J13, observers, or
interested parties. Please indicate on your ballot your organization,
whether your organization is an X3J13 member, and whether your ballot is
the "official" position of your organization.
Reminders:
The fact that a proposal is before you does not mean that the cleanup
committee, or the person(s) listed as the author(s), actually endorse the
proposal. Please read the discussion section if you would like
testimonials.
Several of the proposals are interlinked in important ways. The linkage is
identified in each proposal. Please be careful to not vote for mutually
exclusive proposals.
There are a large number of issues remaining; some already "ready for
release". The selection criteria was to bring to ballot those issues which
were already pending prior to the October 1988 issue. (A few "new" issues
slipped in....) No "slight" of other issues is intended. We will bring to
the January meeting drafts of many of the issues still pending.
Only those issues modified since the October distribution have been
e-mailed to the X3J13 distribution list. All of these issues are available
online for anonymous FTP from host arisia.xerox.com, directory
clcleanup/pending. (User name "anonymous", any password.)
Again, due to my haste in preparing this ballot, there have been several
mistakes and "hasty" issue releases, for which I apologize.
I will not be reading electronic mail until after 3 January, so please send
administrative mail or ballots to cl-cleanup@sail.stanford.edu.
If you wish to mail your ballot in hardcopy form, please
send it to:
Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94022
USA
before January 7.
If you wish to discuss several unrelated issues, please send a separate
message for each issue, preferably with Subject of the form "Re: Issue:
ISSUE-NAME (Version nnnn)".
!
ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Version 5, 5-Dec-88, Mailed 5 Dec 88
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
DECLARATION-SCOPE:NO-HOISTING
DECLARATION-SCOPE:LIMITED-HOISTING
Version 4, 15-Nov-88, Mailed 9-Dec-88
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Version 4, 5-Dec-88, Mailed 5-Dec-88
DECLARE-TYPE-FREE:ALLOW
Version 8, 7-Dec-88, Mailed 9-Dec-88
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
DESCRIBE-INTERACTIVE:NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
EXIT-EXTENT:MINIMAL
EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Version 4, 7-Dec-88, Mailed 12-Dec-88
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
FUNCTION-COMPOSITION:NEW-FUNCTIONS
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
FUNCTION-DEFINITION:FUNCTION-SOURCE
Version 2, 09-Dec-88 , Mailed 9 Dec 88
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Version 7, 8-Dec-88, Mailed 9-Dec-88
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
HASH-TABLE-TESTS:ADD-EQUALP
Version 2, 8-Dec-88, Mailed 8 Dec 88
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
LAMBDA-FORM:NEW-MACRO
Version 4, 22-Nov-88, Mailed 8-Dec-88
LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
LISP-SYMBOL-REDEFINITION:DISALLOW
Version 5, 22-Nov-88, Mailed 8 Dec 88
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
NTH-VALUE:ADD
Version 4, 8-Dec-88, Mailed 8 Dec 88
PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Version 1 27-Jun-88, Mailed 7 Oct 88
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Version 3, 9-Oct-88, Mailed 14-Oct-88
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
REST-LIST-ALLOCATION:MAY-SHARE
REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
TEST-NOT-IF-NOT:FLUSH-ALL
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
∂13-Dec-88 0800 X3J13-mailer CommonLisp/C interface
Received: from goldhill.com ([128.168.1.225]) by SAIL.Stanford.EDU with TCP; 13 Dec 88 07:58:08 PST
Received: by god.goldhill.com; Tue, 13 Dec 88 10:57:48 EST
Date: Tue, 13 Dec 88 10:57:48 EST
From: ejs@goldhill.com (Eric Swenson)
Message-Id: <8812131557.AA14746@goldhill.com>
To: x3j13@sail.stanford.edu
Cc: kahle@think.com
In-Reply-To: kahle@think.com's message of Mon, 12 Dec 88 20:32:57 EST <8812130132.AA13377@ungar.think.com>
Subject: CommonLisp/C interface
We at Gold Hill agree with Brewster's assessment that the lack of
standards vis-a-vis a foreign-function interface are a serious
deficiency for Common Lisp system programmers. Although the Lucid 3.0
foreign function interface may be lacking in some respects, it is
certainly a good starting place. I second the motion to adopt Lucid's
interface as a standard -- or at least the starting point for a standard.
-- Eric Swenson
Gold Hill Computers, Inc.
∂13-Dec-88 0819 X3J13-mailer CommonLisp/C interface
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 08:19:22 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 13 Dec 88 10:29:30 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 13 Dec 88 11:14:54 EST
Date: Tue, 13 Dec 88 11:15 EST
From: Barry Margolin <barmar@Think.COM>
Subject: CommonLisp/C interface
To: kahle@Think.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8812130132.AA13377@ungar.think.com>
Message-Id: <19881213161509.5.BARMAR@OCCAM.THINK.COM>
Date: Mon, 12 Dec 88 20:32:57 EST
From: kahle@Think.COM
We at Thinking Machines have been using Common Lisp as a system programming
language. The principle features that are missing from CommonLisp for this
purpose is the Lisp/C interface specification. This deficiency makes our
code non-portable.
It's a bit late in the process for us to consider an entirely new area
of standardization. We are hoping to get a draft standard out in the
next six months or so. We chartered ourselves with producing a standard
based primarily on CLtL, with the addition of necessary cleanups, an
object-oriented programming facility, error handling, and improved
iteration facilities, and we formed subcommittees to work on each area.
Had we planned on including foreign function calling at that time we
could have formed such a subcommittee, and I am confident that we would
have had something acceptable by this time. But at this time we are
basically finalizing our work, and I think it is not the time to start
discussing a new, potentially controversial aspect of the language.
On the other hand, Lucid has provided a good set of
functions that have gotten better in each release. To start the
discussion:
I propose the Common Lisp committee adopt the Lucid 3.0 foreign function
interface as the Common Lisp standard.
On what do you base this particular recommendation? Yes, Lucid has a
good set of foreign function interfaces, but so do most other vendors.
There was a good article in Lisp Pointers I.5: "Foreign Functions and
Common Lisp", by Harlan Sexton of Lucid. In addition to describing the
existing foreign function interfaces of several Lisps (Franz ExCL, Lucid
CL, and DEC Vax Lisp), he also includes suggestions on what should be in
a standard interface. Since the developer responsible for Lucid's FFI
doesn't feel that it is appropriate for standardization, why do you?
barmar
∂13-Dec-88 0833 X3J13-mailer Re: CommonLisp/C interface
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 08:32:56 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA01286; Tue, 13 Dec 88 08:34:57 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA17218; Tue, 13 Dec 88 08:31:37 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA02234; Tue, 13 Dec 88 08:32:11 PST
Message-Id: <8812131632.AA02234@suntana.sun.com>
To: ejs@goldhill.com (Eric Swenson)
Cc: x3j13@sail.stanford.edu, kahle@think.com
Subject: Re: CommonLisp/C interface
In-Reply-To: Your message of Tue, 13 Dec 88 10:57:48 -0500.
<8812131557.AA14746@goldhill.com>
Date: Tue, 13 Dec 88 08:32:07 PST
From: kempf@Sun.COM
Perhaps we can schedule a discussion and vote at the Hawaii meeting?
jak
∂13-Dec-88 1115 X3J13-mailer [barmar@Think.COM: CommonLisp/C interface]
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Dec 88 11:15:39 PST
Received: from kent-state ([192.9.200.24]) by heavens-gate.lucid.com id AA05058g; Tue, 13 Dec 88 11:12:46 PST
Received: by kent-state id AA01166g; Tue, 13 Dec 88 11:10:11 PST
Date: Tue, 13 Dec 88 11:10:11 PST
From: Harlan Sexton <hbs@lucid.com>
Message-Id: <8812131910.AA01166@kent-state>
To: kahle@Think.COM, barmar@Think.COM, ejs@goldhill.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: Eric Benson's message of Tue, 13 Dec 88 10:00:56 pst <8812131800.AA00280@blacksox>
Subject: [barmar@Think.COM: CommonLisp/C interface]
I am very pleased to hear people pushing for a Common Lisp standard for a
foreign-function interface, and I am especially pleased that they like what
we did at Lucid enough to recommend it as a starting point. As Barry
Margolin mentioned in his mail, I wrote a survey/proposal for CL FFI's
which appeared in Lisp Pointers, and also in Computer Language, Aug. 1988.
(We can send hard-copies or a LaTeX "source" of this article to interested
parties.)
To summarize my views, I like Lucid's FFI best (not too surprising), but
each of the FFI's that I looked at (Franz ExCL, DEC Vax Lisp, Lucid CL)
have features that I feel belong in the standard and that are found in none
of the other FFI's. (KCL has, I think, the best Lisp to C interface of all,
but duplicating that in any other Lisp just doesn't seem feasible.)
Ideally we would have implemented my proposed standard FFI, but it was only
after implementing the one we did and using it that some of its
short-comings were seen. I then looked (again) at what had been done with
some other implementations, thought for awhile, and formulated a proposal
which seemed to add the features missing from what we had done (and to fix
some design warts).
I would be very interested in reactions to my proposal, because it
currently exists only on paper is still very easy to change. I expect that
we will eventually implement this proposal (although it is not scheduled or
even seriously planned at this time), and it would be nice to have some
outside reactions temper the design.
--Harlan
∂13-Dec-88 1120 X3J13-mailer CommonLisp/C interface
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 11:20:12 PST
Received: from fafnir.think.com by Think.COM; Tue, 13 Dec 88 13:31:56 EST
Return-Path: <kahle@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 13 Dec 88 14:18:22 EST
Received: from ungar.think.com by verdi.think.com; Tue, 13 Dec 88 14:16:55 EST
Received: by ungar.think.com; Tue, 13 Dec 88 14:18:18 EST
Date: Tue, 13 Dec 88 14:18:18 EST
From: kahle@Think.COM
Message-Id: <8812131918.AA15056@ungar.think.com>
To: barmar@Think.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 13 Dec 88 11:15 EST <19881213161509.5.BARMAR@OCCAM.THINK.COM>
Subject: CommonLisp/C interface
Date: Tue, 13 Dec 88 11:15 EST
From: Barry Margolin <barmar@Think.COM>
Date: Mon, 12 Dec 88 20:32:57 EST
From: kahle@Think.COM
We at Thinking Machines have been using Common Lisp as a system programming
language. The principle features that are missing from CommonLisp for this
purpose is the Lisp/C interface specification. This deficiency makes our
code non-portable.
It's a bit late in the process for us to consider an entirely new area
of standardization.
...
This is a reasonable reply, of course. I have not followed your committee,
so I am sending this out of the blue.
The reason I bring it up is that the foreign function interface (to C) has
become very important to us. Without a standard we will have a very
difficult time porting much of our software if we ever want to (and we have
no plans to port as far as I know).
On the other hand, Lucid has provided a good set of
functions that have gotten better in each release. To start the
discussion:
I propose the Common Lisp committee adopt the Lucid 3.0 foreign function
interface as the Common Lisp standard.
On what do you base this particular recommendation? Yes, Lucid has a
good set of foreign function interfaces, but so do most other vendors.
There was a good article in Lisp Pointers I.5: "Foreign Functions and
Common Lisp", by Harlan Sexton of Lucid. In addition to describing the
existing foreign function interfaces of several Lisps (Franz ExCL, Lucid
CL, and DEC Vax Lisp), he also includes suggestions on what should be in
a standard interface. Since the developer responsible for Lucid's FFI
doesn't feel that it is appropriate for standardization, why do you?
barmar
I suggested Lucid's interface to get the conversation rolling and no more.
I have not studied the other vendor's interfaces, but the lucid interface
is pretty good. I thought that making a specific recommendation would draw
out counter proposals.
-brewster
brewster@think.com
∂13-Dec-88 1233 X3J13-mailer Re: CommonLisp/C interface
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 13 Dec 88 12:33:39 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA07900; Tue, 13 Dec 88 15:28:14 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA11784; Tue, 13 Dec 88 14:24:15 EST
Message-Id: <8812131924.AA11784@mist.>
To: Barry Margolin <barmar@Think.COM>
Cc: x3j13@sail.stanford.edu, kahle@think.com
Subject: Re: CommonLisp/C interface
In-Reply-To: Your message of Tue, 13 Dec 88 11:15:00 -0500.
<19881213161509.5.BARMAR@OCCAM.THINK.COM>
Date: Tue, 13 Dec 88 14:24:13 EST
From: Dan L. Pierson <pierson@mist.encore.com>
On what do you base this particular recommendation? Yes, Lucid has a
good set of foreign function interfaces, but so do most other vendors.
There was a good article in Lisp Pointers I.5: "Foreign Functions and
Common Lisp", by Harlan Sexton of Lucid. In addition to describing the
existing foreign function interfaces of several Lisps (Franz ExCL, Lucid
CL, and DEC Vax Lisp), he also includes suggestions on what should be in
a standard interface. Since the developer responsible for Lucid's FFI
doesn't feel that it is appropriate for standardization, why do you?
Well, actually Lucid rewrote their foreign function interface to
essentially what's in Harlan's paper for 3.0. So it would seem likely
that the responsible developer does support it.
I agree that it's late in the standardization process to entertain
major new areas. On the other hand, as Larry Masinter pointed out at
the last meeting, the foreign function interface is one of the three
most important remaining areas to standardize. By now, all stock
hardware vendors have significant experience in this area; at least
one vendor has moved to a second generation design (presumably after
discovering shortcomings in their first generation design).
Therefore, we do have a substantial body of current practice and
experience to draw on.
I think it would be well worthwhile to work some on this area and see
if there really is fundamental disagreement before assuming that we
can't succeed in time.
∂14-Dec-88 1043 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 14 Dec 88 10:43:16 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA00847; Wed, 14 Dec 88 13:42:09 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA00470; Wed, 14 Dec 88 13:42:04 EST
Message-Id: <8812141842.AA00470@mist.>
To: Harlan Sexton <hbs@lucid.com>
Cc: x3j13@sail.stanford.edu
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
In-Reply-To: Your message of Tue, 13 Dec 88 11:10:11 -0800.
<8812131910.AA01166@kent-state>
Date: Wed, 14 Dec 88 13:42:02 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I was confused, sorry. Of course your Lisp Pointers paper is
different from the Lucid 3.0 implementation. Your paper also looks
like an improvement, though it is missing a few important features
such as the ability to determine the size of a foreign structure.
We should establish a working group on foreign function interface at
the January meeting. Will you be able to be there?
We should also find a way to move this discussion to another mailing
listt, but I'm afraid that that may be tied up in question of moving
everything off of Sail...
∂14-Dec-88 1157 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 6)
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 14 Dec 88 11:56:23 PST
Received: by goldhill.com; Wed, 14 Dec 88 14:55:55 EST
Date: Wed, 14 Dec 88 14:55:55 EST
From: rpk@goldhill.com (Robert Krajewski)
Message-Id: <8812141955.AA16807@goldhill.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 12 Dec 88 13:44 PST <881212-134536-5049@Xerox>
Subject: Issue: PACKAGE-CLUTTER (Version 6)
I just noticed two problems in this paragraph:
A valid implimentation may have or put additional properties
on symbols (even user created symbols) as long as the
property indicators are not in the LISP, KEYWORD or USER
package.
1. The spelling of the third word.
2. It should be OK for an implementation to use property list indicators
that are *internal* symbols in the LISP package. (Of course, the ``internal''
concept doesn't make sense, really, for keywords, and internal USER symbols
are the most common kind.)
∂14-Dec-88 1205 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Dec 88 12:05:31 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA03961; Wed, 14 Dec 88 12:07:13 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA04016; Wed, 14 Dec 88 12:03:50 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA04870; Wed, 14 Dec 88 11:24:33 PST
Message-Id: <8812141924.AA04870@suntana.sun.com>
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: Harlan Sexton <hbs@lucid.com>, x3j13@sail.stanford.edu
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
In-Reply-To: Your message of Wed, 14 Dec 88 13:42:02 -0500.
<8812141842.AA00470@mist.>
Date: Wed, 14 Dec 88 11:24:09 PST
From: kempf@Sun.COM
>We should establish a working group on foreign function interface at
>the January meeting.
This sounds like an excellent idea.
jak
∂14-Dec-88 1659 X3J13-mailer Hawaii registration
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Dec 88 16:59:14 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA11077g; Wed, 14 Dec 88 16:56:28 PST
Received: by challenger id AA13417g; Wed, 14 Dec 88 16:52:36 PST
Date: Wed, 14 Dec 88 16:52:36 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8812150052.AA13417@challenger>
To: x3j13@sail.stanford.edu
Subject: Hawaii registration
Please let me know if there are any changes/additions. Note that there will
be room to bring guests to the luau, I just need to know how many.
---jan---
X3J13 Attendee Information
12/14/88
Name Institute Paid L1 L2 L3 Luau
Jim Antonisse MITRE Corp. 113.50 y y y 1
Bill Arbaugh U.S. Army -0- y y y -
Paul Beiser HP -0- y y y -
Jerome Chailloix ILOG -0- y y y -
Kathy Chapman DEC -0- y y y 1
Jeff Dalton University of Edinburgh -0- y y y -
Jerry Duggen HP -0- y y y -
Patrick Dussud Lucid, Inc. -0- y y y 1
Dick Gabriel Lucid, Inc. -0- y y y 1
Kevin Layer Franz, Inc. $75.00 y y y 1
Thom Linden IBM $75.00 y y y 1
David Loeffler MCC 113.50 y y y 1
Larry Masinter Xerox $75.00 y y y 1
Greg Nuyens ILOG -0- y y y -
Chris Perdue SUN MicroSystems -0- y y y 1
Jeff Rosenking Grumman Corp. -0- y y y -
David Unietis Lucid, Inc. -0- y y y 1
Mary Van Deusen IBM -0- y y y -
Ellen Waldrum TI $75.00 y y y 2
JonL White Lucid, Inc. -0- y y y 1
Jan Zubkoff Lucid, Inc. -0- y y y 2
∂14-Dec-88 1707 X3J13-mailer Re: CommonLisp/C interface
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Dec 88 17:06:25 PST
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 14 Dec 88 20:03:13 EST
To: Dan L. Pierson <pierson@mist.encore.com>
cc: Barry Margolin <barmar@Think.COM>, x3j13@sail.stanford.edu,
kahle@think.com
Subject: Re: CommonLisp/C interface
In-reply-to: Your message of Tue, 13 Dec 88 14:24:13 -0500.
<8812131924.AA11784@mist.>
Date: Wed, 14 Dec 88 20:00:32 EST
From: Rob.MacLachlan@WB1.CS.CMU.EDU
I agree that a foreign function call mechanism is an important part of any
Common Lisp implementation on an architecture that supports multiple
languages. Nonetheless, I think that attempts to standardize foreign
function call are premature. Good results are especially unlikely under
time pressure.
I believe that the acid test of a foreign interface facility is that it
can be use to define an interface to arbitrary foreign subroutine library.
Use of magical glue code that knows about Lisp or foreign data structure
representations isn't allowed.
Inter-language communication is in general a hard problem. The problem
isn't in calling a routine written in another language, it is with making
foreign data structures sensible. Consider complex data structures: linked
list structures, pointers to arrays of records, etc. Also consider byte
ordering, foreign compiler decisions about record packing, etc.
Since there are spurious proposals in the air, I propose that the CMU
Common Lisp Alien type, the associated C type definition macros, and the
DEFROUTINE macro be made part of Common Lisp. The CMU Lisp facility comes
a lot closer to meeting the desiderata than any other foreign interface
facility that I have seen. For example, we provided a complete interface
to version 10 Xlib without using any glue code.
This is a spurious proposal, since I am sure that our current facility can
be improved quite a bit. It was also never designed to be part of a
portable standard.
In addition to the technical issue of "do we know a good foreign interface
when we see one?", there is the language definition issue of "do we know
how to define a foreign interface mechanism in the Common Lisp context, and
does it make any sense to do so?"
The current standardization effort is undertaking to determine what it
means to "be Common Lisp": what properties all Common Lisp implementations
must have. Availability of C or any other foreign language is not a
required part of the Common Lisp environment, so it doesn't make any sense
to adopt a foreign interface mechanism as part of the core Common Lisp
standard.
People interested in standardizing interface to C should look to what was
done with CLX (the Common Lisp interface to X11.) Informal work on a
mailing list resulted in a Common Lisp extension that is available in
almost all environments where it is meaningful.
Rob
∂15-Dec-88 0929 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Dec 88 09:28:42 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05577; 15 Dec 88 16:27 GMT
Date: Thu, 15 Dec 88 16:38:16 GMT
Message-Id: <6378.8812151638@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
To: kempf@sun.com, "Dan L. Pierson" <pierson%mist.encore.com@NSS.Cs.Ucl.AC.UK>
In-Reply-To: kempf@com.sun's message of Wed, 14 Dec 88 11:24:09 PST
Cc: Harlan Sexton <@sail.stanford.edu:hbs@lucid.com>, x3j13@sail.stanford.edu
>We should establish a working group on foreign function interface at
>the January meeting.
I too think this is a good idea.
It also turns out that the ISO Lisp working group, WG-16, is supposed
to comment on a document, "Working documents on CALLING MECHANISMS
and LANGUAGE-INDEPENDENT DATA TYPES", prepared by WG-11, the working
group for Language Bindings.
Anyone interested in these issues may want to comment, and the plan,
at the last WG-16 meeting, was for anyone interested to prepare
comments by the next WG-16 meeting, in March.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂15-Dec-88 0945 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Dec 88 09:44:51 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA12664; Thu, 15 Dec 88 09:44:56 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA01149; Thu, 15 Dec 88 09:41:36 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA07434; Thu, 15 Dec 88 09:42:10 PST
Message-Id: <8812151742.AA07434@suntana.sun.com>
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Cc: kempf@Sun.COM, "Dan L. Pierson" <pierson%mist.encore.com@NSS.Cs.Ucl.AC.UK>,
Harlan Sexton <@sail.stanford.edu:hbs@lucid.com>,
x3j13@sail.stanford.edu
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
In-Reply-To: Your message of Thu, 15 Dec 88 16:38:16 +0000.
<6378.8812151638@subnode.aiai.ed.ac.uk>
Date: Thu, 15 Dec 88 09:42:08 PST
From: kempf@Sun.COM
Jeff:
Could you bring along a copy of this document to the Hawaii
meeting, presuming you're coming. If not, perhaps you could let
us know where we could get it, or mail it electronically or otherwise?
Thanx.
I'll ask Jan Zubkov about arranging a subcommittee meeting.
jak
∂15-Dec-88 1504 X3J13-mailer Hawaii registration form
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88 15:04:29 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00573g; Thu, 15 Dec 88 15:01:40 PST
Received: by challenger id AA14949g; Thu, 15 Dec 88 14:56:18 PST
Date: Thu, 15 Dec 88 14:56:18 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8812152256.AA14949@challenger>
To: x3j13@sail.stanford.edu
Subject: Hawaii registration form
It's been a while since I've sent this....
X3J13/ISO Meeting
X3J13: 1/16/89 - 1/18/89
ISO: 1/19/89 - 1/20/89
Kauai, Hawaii
Committee Meeting:
Dates: 1/16/89 - 1/18/89
Time: 9:00 - 5:00
City: Kapaa, Kauai, Hawaii
Place: Sheraton Coconut Beach Hotel
REGISTRATION FEE: $75 Payable to: LUCID, Inc.
ISO Meeting:
Dates: 1/19/89 - 1/20/89
Hotel Accomodations:
Hotel: Sheraton Coconut Beach Hotel
Address: Coconut Plantation
Phone: 808/822-3455
Directions from airport:
Turn right onto route 56 north (Kuhio Highway)
Look for the 7 mile marker and take next right (can see hotel from the
road but it is not on the main road)
Rate: $80/night
Mention: "X3J13 Standards Committee" for rate
Group Luau:
Place: Shearton Coconut Grove
Date: 1/17/89
Time: TBA
For further information contact:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
jlz@lucid.com
(415) 329-8400
!
X3J13/ISO January Meeting Registration Form
Please include check for $75.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
jlz@lucid.com
Name: _____________________________________________________________
Institution: ______________________________________________________
Net-Address: ______________________________________________________
Phone: ____________________________________________________________
Attend X3J13 _________ Attend ISO _________
Lunch 1/16: _________ yes _______ no
Lunch 1/17: _________ yes _______ no
Lunch 1/18: _________ yes _______ no
Luau 1/17 $38.50: _________ yes _______ no
∂15-Dec-88 1525 X3J13-mailer Hawaii registration form OOOPS!
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88 15:25:46 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00611g; Thu, 15 Dec 88 15:22:51 PST
Received: by challenger id AA15067g; Thu, 15 Dec 88 15:18:58 PST
Date: Thu, 15 Dec 88 15:18:58 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8812152318.AA15067@challenger>
To: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Thu, 15 Dec 88 14:56:18 PST <8812152256.AA14949@challenger>
Subject: Hawaii registration form OOOPS!
Scratch the ISO meeting from the registration form. It really has been
cancelled.
---jan---
∂15-Dec-88 1715 X3J13-mailer Symbolics Cambridge office is moving
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Dec 88 17:15:23 PST
Date: Thu, 15 Dec 88 20:16:17 EST
From: KMP@STONY-BROOK.SCRC.Symbolics.COM
Sender: KMP@AI.AI.MIT.EDU
Subject: Symbolics Cambridge office is moving
To: X3J13@SAIL.STANFORD.EDU
Message-ID: <505706.881215.KMP@AI.AI.MIT.EDU>
The Symbolics Cambridge office (corporate HQ and R&D) is moving to
Burlington this week. Our file servers will be offline for some of
the transition and mail to me, Moon, etc. may bounce. If you get
back mail because Symbolics doesn't respond (and if it's possible,
convenient, etc.), please hang onto any bounced messages and
re-send them to us mid next week when things will (hopefully) be
back in order. Thanks very much.
∂16-Dec-88 0847 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 16 Dec 88 08:47:33 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05376; 16 Dec 88 16:11 GMT
Date: Fri, 16 Dec 88 16:22:55 GMT
Message-Id: <7682.8812161622@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
To: kempf@sun.com, x3j13@sail.stanford.edu
In-Reply-To: kempf@com.sun's message of Thu, 15 Dec 88 09:42:08 PST
Cc: pierson <@NSS.Cs.Ucl.AC.UK:pierson@mist.encore.com>,
hbs <@sail.stanford.edu:hbs@lucid.com>
> Could you bring along a copy of this document to the Hawaii
> meeting, presuming you're coming. If not, perhaps you could let
> us know where we could get it, or mail it electronically or otherwise?
Dick Gabriel should have received a copy fro ISO. I've received
several by now, via various paths, and will try to remmeber to
bring one.
-- Jeff
∂19-Dec-88 2242 X3J13-mailer Corrections to the ISO Report
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Dec 88 22:42:08 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03191g; Mon, 19 Dec 88 22:39:08 PST
Received: by challenger id AA19722g; Mon, 19 Dec 88 22:35:13 PST
Date: Mon, 19 Dec 88 22:35:13 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8812200635.AA19722@challenger>
To: x3j13@sail.stanford.edu
Subject: Corrections to the ISO Report
Colleagues:
There have been a couple of questions directed privately to me about
my ISO meeting report. I think the answers are of general interest, so
I will direct them to the X3J13 mailing list.
1. The first regards the Japanese position on CLOS. I believe there
are two concerns that the Japanese have: one is that the CLOS
specification is difficult to read and thus is difficult to evaluate;
the other is that CLOS is comparatively new and represents relatively
recent research, which leads them to believe that it would be good to
gather some practical experience with it before international
standardization. I believe this is a reasonable position. I believe
the US must make its case convincingly for the Japanese to agree to
adopting CLOS into a near-term international standard.
2. There was a wording problem with my comments on the AFNOR
delegation's response to the US position. The US indeed voted to
accept the New Work Item that is the basis for the establishment of
WG16. At the first meeting AFNOR proposed a work plan (which I
inaccurately referred to as a ``work item''). The proposed work plan
is to adopt Common Lisp as the starting point for IsLisp but to try to
alter Common Lisp in certain ways. The structure of the work plan is
to identify features of Common Lisp that WG16 should alter and to
associate with the feature a default. For each such feature, if no
acceptable technical alternative to the feature is determined within a
reasonable time period, the default replaces the feature. For
example, the package system is on the list of features to alter, and
if no better solution than the current Common Lisp package system is
determined, the default is to provide only a flat namespace - that is,
the default is no package system. The US did not agree to this work
plan, and the evidence for this is simply that the acceptability of
the work plan never came to a vote at WG16. Therefore, the US did not
change its position regarding this work plan, and the current US
position is the first time the US took any position with regard to the
work plan for WG16 proposed by the AFNOR delegation.
When the AFNOR delegation stated that the US position represented a
``preposterous'' change in position by the US, I interpreted their
statement as a response to an incorrectly perceived change in position
by the US regarding the never-agreed-on AFNOR-proposed work plan. The
only alternative interpretation I could think of is that the AFNOR
delegation incorrectly perceived a change in position by the US to the
New Work Item that defines the goal of WG16. Since the latter
interpretation is illogical, I adopted the other one.
3. There was a minor error in my report on the presentation by Mr
Kurokowa. The following is the amended section (the word that should
be deleted is in [square brackets]):
``Mr Kurokowa presented a report on Japanese activity on provisions
within [Common] Lisp for international character sets. Thom Linden
presented the latest X3J13 work on the same topic. In addition, the
U.S. was asked to present the current WG16 status on character
handling at the next SC22 meeting.''
That is, Mr Kurokowa discussed international character set handling
for an internationally standardized Lisp and not for Common Lisp.
-rpg-
∂20-Dec-88 0233 X3J13-mailer Gabriel's report
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 20 Dec 88 02:33:05 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab19605; 20 Dec 88 4:03 EST
Received: from utokyo-relay by RELAY.CS.NET id ab03791; 20 Dec 88 3:58 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA21505; Tue, 20 Dec 88 16:24:50 JST
Received: by nttlab.ntt.jp (3.2/6.2NTT.h) with TCP; Tue, 20 Dec 88 15:56:01 JST
Received: by tutics.tut.junet (ver3.3/6.2J/systemV)
id AA07407; Tue, 20 Dec 88 12:37:46 jst
Message-Id: <8812201237.AA07407@tutics.tut.junet>
Date: Tue, 20 Dec 88 12:37:46 jst
From: Taiichi Yuasa <yuasa%tutics.tut.junet@UTOKYO-RELAY.CSNET>
To: x3j13@SAIL.STANFORD.EDU
Subject: Gabriel's report
Cc: RPG@SAIL.STANFORD.EDU
As a secretary of Japanese SC22/LISP WG, I have some comments on Richar
d
Gabriel's report on the November ISO meeting.
> Mr. Kurokawa presented a report on Japanese activity on
> provisions within Common Lisp for international character sets.
This sentence is wrong. The Japanese SC22/LISP WG is working for ISO
standard, but NOT for Common Lisp standard. Mr. Kurokawa is supposed t
o
have presented (and he confirmed me that he indeed presented) a Japanes
e
contribution on international character set handling within ISO standar
d,
but not necessarily within Common Lisp. He may have used some Common L
isp
terminology, but this is because of the WG16 agreement that Common Lisp
be a starting point.
> Professor Ito
> is primarily concerned about CLOS,
This is true. And, this is not only his personal concern, but a genera
l
concern of Japanese Lisp WG as well. It seems to me that this is a mor
e
general concern of the Japanese computer science community, since CLOS
has not received a citizenship in object-oriented world in Japan.
> but after private discussions I
> learned that because of lack of study he did not understand it,
This is not true. I know he fully understands CLOS. Note, however, th
at
it is painful to read the CLOS document, especially when no one has off
icially
proposed it to WG16, and when inclusion of CLOS to ISO standard is so d
oubtful
in one's country.
> and
> the expert group that advises him consists of object-oriented
> programming researchers who press their own ideas on him.
I'm afraid this sentence came from Gabriel's misunderstanding or prejud
ice
about Japanese activities for Lisp standardization. Prof. Ito himself
is a programming expert (he is one of the first Lisp hackers in Japan)
and
his opinion has been reflected to "the expert group" to a great extent.
Programming experts including Prof. Ito himself is working very hard fo
r
ISO standard, as well as investigating their own ideas.
To sum up, I found the sentences of Gabriel's report concerning with
Japanese activities are quite misleading. I hope my comments can
help you avoid misinterpretation of these sentences.
-- Taiichi Yuasa
∂20-Dec-88 0757 X3J13-mailer Re: Gabriel's report
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 20 Dec 88 07:57:15 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA28013; Tue, 20 Dec 88 07:59:03 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA28535; Tue, 20 Dec 88 07:55:43 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA18561; Tue, 20 Dec 88 07:56:17 PST
Message-Id: <8812201556.AA18561@suntana.sun.com>
To: Taiichi Yuasa <yuasa%tutics.tut.junet@UTOKYO-RELAY.CSNET>
Cc: x3j13@SAIL.STANFORD.EDU, RPG@SAIL.STANFORD.EDU
Subject: Re: Gabriel's report
In-Reply-To: Your message of Tue, 20 Dec 88 12:37:46 +0200.
<8812201237.AA07407@tutics.tut.junet>
Date: Tue, 20 Dec 88 07:56:14 PST
From: kempf@Sun.COM
>concern of Japanese Lisp WG as well. It seems to me that this is a more
>general concern of the Japanese computer science community, since CLOS
>has not received a citizenship in object-oriented world in Japan.
What, precisely, is the Japanese concern with CLOS? The committee has
made an effort over the past 2 years to remain open to suggestions
about modifying the design. There have been several electronic mail
messages from someone in Japan on the subject (it may have been Prof. Ito)
which have been taken into account during the design. What changes do
the Japanese delegates feel are needed (if any) for CLOS to receive
"full citizenship" in the Japanese object-oriented world, presuming,
of course, that Common Lisp is accepeted as an adequate base? Is there
a reasonable chance that CLOS can achieve that status, or do most
Japanese object-oriented programmers feel more confortable using Smalltalk?
jak
∂20-Dec-88 1137 X3J13-mailer access to the standard
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Dec 88 11:37:37 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA29610; Tue, 20 Dec 88 11:36:35 PST
Message-Id: <8812201936.AA29610@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Dec 88 14:02
To: x3j13@sail.stanford.edu
Subject: access to the standard
Following is the updated account information for accessing the
working draft of the standard:
Username: ftp_user
Password: merrychristmas
Node: hudson@dec.com
The password has changed.
kc
∂22-Dec-88 1139 X3J13-mailer Error terminology
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 Dec 88 11:39:15 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04427g; Wed, 21 Dec 88 22:05:23 PST
Received: by bhopal id AA10159g; Wed, 21 Dec 88 22:06:00 PST
Date: Wed, 21 Dec 88 22:06:00 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812220606.AA10159@bhopal>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 3 Oct 88 15:42 <8810031951.AA06841@decwrl.dec.com>
Subject: Error terminology
re: - THE "CONSEQUENCES ARE UNSPECIFIED"
means that
. . .
- ... and all portable programs are required to treat
the situation as unpredictable but harmless.
It looks like to me that "harmless" has the same lack of specificity
as Barry's word "benign". Taken in context of the rest of your message,
it could only mean "not fatal". Is that good enough?
[By the bye, was this msg really intended for x3j13 distribution? or
should it have been cl-editorial?]
-- JonL --
∂22-Dec-88 1241 X3J13-mailer Re: Corrections to the ISO Report
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Dec 88 12:35:20 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06698; 22 Dec 88 20:30 GMT
Date: Thu, 22 Dec 88 20:27:12 GMT
Message-Id: <20454.8812222027@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Corrections to the ISO Report
To: rpg <@sail.stanford.edu:rpg@lucid.com>, x3j13@sail.stanford.edu
In-Reply-To: Richard P. Gabriel's message of Mon, 19 Dec 88 22:35:13 PST
> 2. There was a wording problem with my comments on the AFNOR
> delegation's response to the US position.
I think there are two issues. One is that the NWI does not talk
about multiple standards for multiple varieties ("dialects" might
be prejudicial) of Lisp. At the first WG-16 meeting in Paris,
the US made the point that an ISO standard named something like
"ISO Lisp" might seem to preclude standards for other varieties
of Lisp but there was not, as far as I can recall (I haven't checked
my notes), anything said about multiple standards under the current
Work Item. The US seemed willing then to have WG-16 work on a
single standard, even one based on Common Lisp. Indeed, the US
insisted that the WG-16 schedule (the 18 months) required a starting
point in existing work, and the US voted for "Common Lisp or Scheme"
as the starting point.
This brings us to the second issue, for which you have found the
convenient term "work plan". I think the following is a fair
summary:
1. At the first WG-16, the US cooperated in drafting the work
plan and did not voice strong objections. We can contrast
this with the US approach to the name of the standard, where
the US made it clear that "ISO Lisp" was unacceptable.
However, the US made the point that any deviation from
CL would need an environmental impact statement.
2. At the second WG-16, the US was unhappy with some of the defaults
and preferred that changes be deletions (so that the ISO standard
would be a strict rather than "extended" subset). It was
explained, by the Convenor and others, that the default values
would not be adopted just because they were the defaults. The
US seemed to accept this explanation.
3. Before the third WG-16, the US distributed a position statement
which, in effect, said that the US would oppose any changes to
Common Lisp that were not deletions. This was a hardening of
what seemed to be the US position in the second meeting, because
changes would be opposed simply because they were not deletions,
regardless of technical or practical merit. (Of course,
deletions might still be opposed on those grounds, and such
reasons might be given as additional reasons for opposing
non-deletions.)
So, it appears to me that the US position has changed. Whether it
is a "preposterous" change is less clear. It might be argued that
the position has evolved. Nonetheless,
> The US did not agree to this work plan, and the evidence for this
> is simply that the acceptability of the work plan never came to a
> vote at WG16. Therefore, the US did not change its position regarding
> this work plan, and the current US position is the first time the US
> took any position with regard to the work plan for WG16 proposed by the
> AFNOR delegation.
It can be argued that the US has officially said only three things.
One is the comment on the NWI stating opposition to the name "ISO
Lisp". Another is the position statement distributed before the
3rd WG-16. Then, finally, there's the proposal for an ISO Common
Lisp standard presented at the 3rd meeting. Indeed, it might be
argued that only the first is really official, because only it
involved a vote in X3J13 (if even that is enough). However, if
we're to take a "letter of the law" approach, it must be noted that
a change from no official position to official opposition is still
a change.
There is one additional point I would like to make. Although the
initial list of issues and defaults, and the idea that we should
proceed in this way, came from AFNOR, the final list was the result
of comments by other countries, including the US. Moreover, there
appeared to be a consensus (that included the US) on the following
statement:
The draft standard to be provided by the Working Group within
18 months will take as starting point Common Lisp (with X3J13
cleanups) with treatment of major issues and default values
to be identified (including issues in the AFNOR list and on
agenda).
> When the AFNOR delegation stated that the US position represented a
> ``preposterous'' change in position by the US, I interpreted their
> statement as a response to an incorrectly perceived change in position
> by the US regarding the never-agreed-on AFNOR-proposed work plan. The
> only alternative interpretation I could think of is that the AFNOR
> delegation incorrectly perceived a change in position by the US to the
> New Work Item that defines the goal of WG16. Since the latter
> interpretation is illogical, I adopted the other one.
I think you were right to adopt the other one.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂22-Dec-88 1447 X3J13-mailer Re: Corrections to the ISO Report
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Dec 88 14:45:02 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06698; 22 Dec 88 20:30 GMT
Date: Thu, 22 Dec 88 20:27:12 GMT
Message-Id: <20454.8812222027@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Corrections to the ISO Report
To: rpg <@sail.stanford.edu:rpg@lucid.com>, x3j13@sail.stanford.edu
In-Reply-To: Richard P. Gabriel's message of Mon, 19 Dec 88 22:35:13 PST
> 2. There was a wording problem with my comments on the AFNOR
> delegation's response to the US position.
I think there are two issues. One is that the NWI does not talk
about multiple standards for multiple varieties ("dialects" might
be prejudicial) of Lisp. At the first WG-16 meeting in Paris,
the US made the point that an ISO standard named something like
"ISO Lisp" might seem to preclude standards for other varieties
of Lisp but there was not, as far as I can recall (I haven't checked
my notes), anything said about multiple standards under the current
Work Item. The US seemed willing then to have WG-16 work on a
single standard, even one based on Common Lisp. Indeed, the US
insisted that the WG-16 schedule (the 18 months) required a starting
point in existing work, and the US voted for "Common Lisp or Scheme"
as the starting point.
This brings us to the second issue, for which you have found the
convenient term "work plan". I think the following is a fair
summary:
1. At the first WG-16, the US cooperated in drafting the work
plan and did not voice strong objections. We can contrast
this with the US approach to the name of the standard, where
the US made it clear that "ISO Lisp" was unacceptable.
However, the US made the point that any deviation from
CL would need an environmental impact statement.
2. At the second WG-16, the US was unhappy with some of the defaults
and preferred that changes be deletions (so that the ISO standard
would be a strict rather than "extended" subset). It was
explained, by the Convenor and others, that the default values
would not be adopted just because they were the defaults. The
US seemed to accept this explanation.
3. Before the third WG-16, the US distributed a position statement
which, in effect, said that the US would oppose any changes to
Common Lisp that were not deletions. This was a hardening of
what seemed to be the US position in the second meeting, because
changes would be opposed simply because they were not deletions,
regardless of technical or practical merit. (Of course,
deletions might still be opposed on those grounds, and such
reasons might be given as additional reasons for opposing
non-deletions.)
So, it appears to me that the US position has changed. Whether it
is a "preposterous" change is less clear. It might be argued that
the position has evolved. Nonetheless,
> The US did not agree to this work plan, and the evidence for this
> is simply that the acceptability of the work plan never came to a
> vote at WG16. Therefore, the US did not change its position regarding
> this work plan, and the current US position is the first time the US
> took any position with regard to the work plan for WG16 proposed by the
> AFNOR delegation.
It can be argued that the US has officially said only three things.
One is the comment on the NWI stating opposition to the name "ISO
Lisp". Another is the position statement distributed before the
3rd WG-16. Then, finally, there's the proposal for an ISO Common
Lisp standard presented at the 3rd meeting. Indeed, it might be
argued that only the first is really official, because only it
involved a vote in X3J13 (if even that is enough). However, if
we're to take a "letter of the law" approach, it must be noted that
a change from no official position to official opposition is still
a change.
There is one additional point I would like to make. Although the
initial list of issues and defaults, and the idea that we should
proceed in this way, came from AFNOR, the final list was the result
of comments by other countries, including the US. Moreover, there
appeared to be a consensus (that included the US) on the following
statement:
The draft standard to be provided by the Working Group within
18 months will take as starting point Common Lisp (with X3J13
cleanups) with treatment of major issues and default values
to be identified (including issues in the AFNOR list and on
agenda).
> When the AFNOR delegation stated that the US position represented a
> ``preposterous'' change in position by the US, I interpreted their
> statement as a response to an incorrectly perceived change in position
> by the US regarding the never-agreed-on AFNOR-proposed work plan. The
> only alternative interpretation I could think of is that the AFNOR
> delegation incorrectly perceived a change in position by the US to the
> New Work Item that defines the goal of WG16. Since the latter
> interpretation is illogical, I adopted the other one.
I think you were right to adopt the other one.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂03-Jan-89 1228 X3J13-mailer Hawaii registration status
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 12:27:56 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03395g; Tue, 3 Jan 89 12:24:09 PST
Received: by challenger id AA07960g; Tue, 3 Jan 89 12:20:10 PST
Date: Tue, 3 Jan 89 12:20:10 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901032020.AA07960@challenger>
To: x3j13@sail.stanford.edu
Subject: Hawaii registration status
Please let me know if you have any changes.
---jan---
X3J13 Attendee Information
01/03/89
Name Institute Paid L1 L2 L3 Luau
Jim Antonisse MITRE Corp. 113.50 y y y 1
Bill Arbaugh U.S. Army -0- y y y -
Kim Barrett Integrated Inference 113.50 y y y 1
David Bartley Texas Instruments $75.00 y y y -
Paul Beiser HP -0- y y y -
Skona Brittan Microcomputer Systems -0- y y y -
Jerome Chailloix ILOG -0- y y y -
Kathy Chapman DEC -0- y y y 2
Jeff Dalton University of Edinburgh -0- y y y 1
Jerry Duggen HP -0- y y y 2
Patrick Dussud Lucid, Inc. -0- y y y 1
Dick Gabriel Lucid, Inc. -0- y y y 3
George Hadden Honeywell -0- y y y 2
Jim Kempf SUN Microsytsems -0- y y y 1
Gregor Kiczales Xerox Corp. -0- y y y 1
Aaron Larson Honeywell -0- y y y 2
Kevin Layer Franz, Inc. $75.00 y y y 1
Thom Linden IBM $75.00 y y y 3
David Loeffler MCC 113.50 y y y 1
Sandra Loosemore University of Utah -0- y y y -
Barry Margolin Thinking Machines, Inc. 113.50 y y y y
Larry Masinter Xerox $75.00 y y y 1
Robert Mathis CONTEL -0- y y y 4
David Moon Symbolics, Inc. -0- 1 1 1 -
Greg Nuyens ILOG -0- y y y -
Chris Perdue SUN MicroSystems -0- y y y 1
Dan Pierson Encore Computer -0- y y y 1
Jeff Rosenking Grumman Corp. -0- y y y -
Paul Tucker IBM -0- y y y 2
David Unietis Lucid, Inc. -0- y y y 1
Mary Van Deusen IBM -0- y y y -
Ellen Waldrum TI $75.00 y y y 2
JonL White Lucid, Inc. -0- y y y 1
Gail Zacharias Coral Software Corp. -0- y y y 2
Jan Zubkoff Lucid, Inc. -0- y y y 2
∂03-Jan-89 1324 X3J13-mailer issues from cl-compiler
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 13:24:43 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA27137; Tue, 3 Jan 89 14:23:35 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA05977; Tue, 3 Jan 89 14:23:33 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032123.AA05977@defun.utah.edu>
Date: Tue, 3 Jan 89 14:23:32 MST
Subject: issues from cl-compiler
To: x3j13@sail.stanford.edu
I will be sending out a number of issues from the compiler committee
over the next several days. We plan to discuss these at the upcoming
meeting and vote on any that appear to be noncontroversial. Some of
the issues are marked **DRAFT**; these are issues that we do not feel
have had enough consideration to be voted upon yet, but where we would
like to get feedback from a larger group.
Please send comments on these issues to cl-compiler@sail.stanford.edu
(-not- to the X3J13 mailing list). Alternatively, we will consider
amendments at the upcoming meeting. (Having your amendment written
down in advance will help considerably in reducing confusion.)
-Sandra
-------
∂03-Jan-89 1424 X3J13-mailer issue ALLOW-LOCAL-INLINE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:24:12 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00523; Tue, 3 Jan 89 15:23:04 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06032; Tue, 3 Jan 89 15:23:02 MST
Date: Tue, 3 Jan 89 15:23:02 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032223.AA06032@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue ALLOW-LOCAL-INLINE
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: ALLOW-LOCAL-INLINE
References: CLtL p. 156, 159
Related issues: PROCLAIM-INLINE-WHERE
Category: CLARIFICATION
Edit History: 21 Sept. 88 V1 by David Gray
27 Oct. 88 V2 by David Gray - new proposal
9 Nov. 88 V3 by David Gray - expanded problem
description and discussion sections.
30 Dec. 88 V4 by Sandra Loosemore -- suggestions from Pitman
Problem Description:
The proposal PROCLAIM-INLINE-WHERE:BEFORE (which was accepted by X3J13
on 10/12/88) clarifies the use of INLINE proclamations, but there
remains a similar problem with the use of a local (DECLARE (INLINE
...)): how can the compiler expand the function inline if it didn't
know that the necessary information should have been saved when the
function was compiled?
Note that an INLINE proclamation does two things:
(1) It tells the compiler to do extra things when it sees the
function -definition-, to make it possible to code the function
inline.
(2) It tells the compiler to code -calls- to the function inline.
In order for local INLINE declarations to be useful, we need part 1
without part 2.
Proposal ALLOW-LOCAL-INLINE:INLINE-NOTINLINE
Clarify that to define a function FOO which is not INLINE by default
but for which (DECLARE (INLINE FOO)) will make FOO be locally inlined,
the proper definition sequence is:
(PROCLAIM '(INLINE foo))
(DEFUN foo ...)
(PROCLAIM '(NOTINLINE foo))
The INLINE proclamation preceding the DEFUN ensures that compiler will
save the information necessary for inline expansion, and the NOTINLINE
proclamation following the DEFUN prevents it from being expanded
inline everywhere.
Note that while implementations are never required to perform inline
expansion of function calls, many implementations that do support
inline expansion will not be able to respond to local INLINE requests
if this technique is not followed.
Rationale:
Local INLINE declarations are of little use without some way of
alerting the compiler to the possibility of inline expansion before
the function is compiled. This seems the simplest solution since it
just clarifies existing practice instead of adding a new feature to
the language.
A compiler could use some heuristic to save the definitions of functions
that are short enough to look like good candidates for inline expansion,
but then the user is never sure what to expect. It is possible that a
compiler could simply save all definitions (assuming availability
of adequate storage space) but we shouldn't require that.
Test Cases/Examples:
Given the following input to COMPILE-FILE, does F1 get expanded inline
in F2, and does F3 get expanded inline in F4?
(defun f1 (a) (+ a 100))
(defun f2 (b) (declare (inline f1)) (f1 b))
(proclaim '(inline f3))
(defun f3 (a) (+ a 100))
(proclaim '(notinline f3))
(defun f4 (b) (f3 b)) ;F3 is not inline.
(defun f5 (c) (declare (inline f3)) (f3 c)) ;F3 is locally inline.
(defun f6 (c) (f3 c)) ;The local effect is not
; persistent.
Current Practice:
In the example above, using Symbolics, Lucid, or Explorer, F1 is not
expanded in F2, but F3 is expanded in F5.
Cost to implementors:
None, since this is a clarification in accordance with current
practice.
Cost to users:
None.
Benefits:
Users will be able to use (DECLARE (INLINE ...)) with greater assurance
that it will really do something.
Costs of Non-Adoption:
Users will not know how to reliably request inline expansion on a
local basis. This technique is not obvious, and even the need
for it likely to be apparent only to people who understand something
about how the compiler does inline expansion.
Discussion:
Version 1 of this issue included proposal
ALLOW-LOCAL-INLINE:PROCLAIM-ALLOW-INLINE to make an addition to the
language:
(PROCLAIM '(ALLOW-INLINE foo))
This was met with a lack of enthusiasm since it was pointed out that
the same effect could be obtained by using a combination of INLINE and
NOTINLINE.
This is may not be completely true, however, since people's thinking
about NOTINLINE has evolved in the direction of a declaration that
tells the compiler "assume nothing about this function". Thus, a
NOTINLINE proclamation might suppress some optimizations that would
have occurred if there had never been an INLINE and NOTINLINE.
Ideally, it would be nice to have multiple levels of control instead
of just INLINE or NOTINLINE -- something like:
* always inline
* maybe inline (let the compiler decide)
* just save the definition for possible local inline
* default
* never inline
Pitman has said that he generally approves of the direction of this
proposal, but he has also expressed concerns about how the persistance
of INLINE proclamations may cause confusion when functions are redefined
in an incremental development environment.
∂03-Jan-89 1428 X3J13-mailer issue DEFCONSTANT-SPECIAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:28:00 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00602; Tue, 3 Jan 89 15:26:55 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06038; Tue, 3 Jan 89 15:26:53 MST
Date: Tue, 3 Jan 89 15:26:53 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032226.AA06038@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue DEFCONSTANT-SPECIAL
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: DEFCONSTANT-SPECIAL
References: CLtL p. 68-69, 55-56
Issue DEFCONSTANT-NOT-WIRED
Issue PROCLAIM-LEXICAL
Issue SYNTACTIC-ENVIRONMENT-ACCESS
Issue SPECIAL-VARIABLE-TEST
Category: CLARIFICATION
Edit History: V1, 15 Nov 1988, Sandra Loosemore
V2, 22 Nov 1988, Sandra Loosemore
V3, 30 Dec 1988, Sandra Loosemore
Problem Description:
It is unclear whether DEFCONSTANT is supposed to proclaim the variable
SPECIAL. Page 56 says that symbols defined by DEFCONSTANT "may not be
further assigned to or bound". Page 69 says that "further assignment
to or binding of that special variable is an error" but permits
compilers to "choose to issue warnings about bindings of the lexical
variable of the same name". Does this mean that it is legal (but
perhaps only questionable style) to lexically rebind constants? If
so, this would seem to imply that they must not be proclaimed SPECIAL
(since CLtL provides no way to override a SPECIAL proclamation).
Some people think that DEFCONSTANT is supposed to proclaim the
variable SPECIAL because CLtL says that DEFVAR does, and that
DEFPARAMETER is like DEFVAR, and DEFCONSTANT is like DEFPARAMETER.
Also, the use of the phrase "that special variable" rather than "the
special variable of the same name" might indicate that the variable
really is supposed to be special.
Proposal DEFCONSTANT-SPECIAL:NO:
Clarify that DEFCONSTANT does not proclaim the variable special, but
that it is an error to rebind constant symbols as either lexical or
special variables. (In other words, a reference to a symbol declared
with DEFCONSTANT always refers to its global value.)
Rationale:
If DEFCONSTANT declared the variable special, the lexical rebindings
mentioned on p. 69 could never arise. Clarifying that lexical
rebinding (as well as special rebinding) of constants "is an error"
seems to be the behavior that most users expect. One serious problem
that might arise from allowing constants to be rebound lexically is
that it would not be reliable to include symbolic constants in macro
expansions, because the user might have rebound them to something
else.
Current Practice:
Most implementations apparently proclaim the variable special anyway.
Cost to implementors:
Minor.
Cost to users:
Probably none. Since many implementations do proclaim the variable to
be special (while at the same time forbidding special binding), there
is probably no user code that depends upon lexical rebinding of
DEFCONSTANTs.
Benefits:
An area of confusion in the language is removed.
Discussion:
This issue is primarily a documentation clarification. It arose
during a discussion of what the DEFCONSTANT macro might expand into.
As far as users are concerned, it makes no difference whether
constants are special or lexical, as long as all rebinding is
prohibited. The only situation where the distinction might become
important is if a function is added to the language to test whether a
variable has been proclaimed special.
The "problem description" section of the writeup on issue
PROCLAIM-LEXICAL (version 8) also appears to assume that constants
declared with DEFCONSTANT are not special.
∂03-Jan-89 1426 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:25:59 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00548; Tue, 3 Jan 89 15:24:53 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06035; Tue, 3 Jan 89 15:24:49 MST
Date: Tue, 3 Jan 89 15:24:49 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032224.AA06035@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILE-ENVIRONMENT-CONSISTENCY
References: CLtL p. 68-69, 143, 321
RAM's "Compiler Cleanup Proposal #3"
Category: CLARIFICATION
Edit History: V1, 2 Sep 1988, Sandra Loosemore (initial draft)
V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions)
V3, 26 Oct 1988, Sandra Loosemore (add suggestion from Benson)
Problem Description:
CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled.
Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:
Common Lisp deliberately leaves unspecified the time at which certain
transformations, such as macro expansion, are performed within a
program. While some implementations perform such transformations
concurrently with evaluation, it is also legitimate to perform
transformations during a preprocessing phase. For example, an
implementation might choose to apply transformations at "function
promotion time" (i.e., transformations are applied once during
evaluation of a surrounding FUNCTION special form), or to completely
transform each top-level form and all of its subforms before
performing any evaluation. User programs cannot portably depend upon
either the time of such transformations, or the number of times the
transformations are applied.
In all cases, however, compiling a program (with COMPILE or
COMPILE-FILE) provides a mechanism for forcing these transformations
to be applied and a guarantee that, once compiled, no further
transformations will be applied to that program.
In the discussion that follows, the term "compiler" is to be understood
to include other preprocessors as well. Likewise, the "compiletime
environment" refers to the environment in which program transformations
occur, while "runtime" refers to the time the program is executed.
(1) The following information *must* be present in the compiletime
environment for the preprocessor to apply the correct transformations.
This information need not also be present in the runtime environment.
(a) Macro definitions must be available in the compiletime environment.
The compiler may assume that forms that are lists beginning with
a symbol that does not name a macro or special form is a function
call. (This implies that SETF methods must also be available at
compiletime.)
(b) Special variables must be declared as such before they are bound.
The compiler must treat any undeclared variable binding as a
lexical binding.
(2) The compiler *may* "wire in" the following kinds of information
into the code it produces, if the information is present in the
compiletime environment. However, since implementations are not
required to do this, user code must ensure that the information is
also defined consistently in the runtime environment. Except as
noted, the behavior of user programs is unspecified in situations
where the information is defined differently at runtime than at
compiletime, since the user cannot depend upon which will take
precedence in a particular implementation. In all cases, the absence
of the information at compiletime is not an error, but its presence
may enable the compiler to do a better job.
(a) The compiler may assume that functions that are defined and
declared INLINE in the compiletime environment will retain the
same definitions at runtime.
(b) The compiler may assume that, within a named function, a
recursive call to a function of the same name refers to the
same function, unless that function has been declared NOTINLINE.
(c) COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at runtime.
(d) The compiler may assume that the signature (or "contract") of
all built-in Common Lisp functions will not change. In addition,
the compiler may treat all built-in Common Lisp functions as if
they had been proclaimed INLINE.
(e) The compile may assume that the signature (or "contract") of
functions with FTYPE information available will not change. (See
issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS.)
(f) The compiler may "wire in" the values of symbolic constants
that have been defined with DEFCONSTANT in the compiletime
environment.
(g) Types that are defined with DEFTYPE or DEFSTRUCT can be assumed to
retain the same definition in the runtime environment as in the
compiletime environment. (Note that it is not an error for an
unknown type to appear in a declaration at compiletime, although
it is reasonable for the compiler to emit a warning in such a
case.)
(h) The compiler may assume that a class name defined by DEFCLASS
that is present in the compiletime environment will also be a
class name at runtime, and that class will be an instance of the
same metaclass. There may be additional conformance requirements
imposed by the metaclass, but there are none for STANDARD-CLASS.
(i) The compiler may assume that if type declarations are present
in the compiletime environment, the corresponding variables and
functions present in the runtime environment will actually be of
those types; otherwise, the behavior of the program is undefined.
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not assume that functions that are defined
in the compiletime environment will retain the either the
same definition or the same signature at runtime, except
in situations (2a) through (2e) above. It is, however,
reasonable for the compiler to emit warning messages about
calls to functions that are defined at compiletime, but where
the wrong number or type of arguments are supplied.
(b) The compiler may not signal an error if it sees a call to a
function that is not defined at compiletime, since that function
may be provided at runtime. Again, it is permissible to emit
a warning in these situations.
Rationale:
This proposal generally reflects current practice.
Current Practice:
I know of no compiler that does not implement the provisions of item (1).
For item (2), most compilers (including Lucid) optimize self-recursive
calls by default. Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well. VaxLisp, for
example, normally compiles MEMBER inline. The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining. KCL performs block compilation by default,
and Lucid does so under certain conditions.
Cost to implementors:
Unknown, but probably minor.
Cost to users:
Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.
Benefits:
The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.
Discussion:
Most of the discussion on this issue has been centered on the
terminology describing error situations for item (2). In most cases
where there is an inconsistency between compile-time and run-time, the
results will be unpredictable but harmless. The major exception is
violation of type declarations, which is a "crash-and-burn" error in
many implementations.
There has also been some concern raised that item (3) would prohibit
such things as a cross-compiler that produces standalone programs in
an environment that disallows redefinition of functions. The intent
of this proposal is not to prohibit a compiler from having a magic
switch that imposes additional restrictions on the programs it
compiles, but such a compiler would not be a compiler for Common Lisp.
∂03-Jan-89 1432 X3J13-mailer issue SHARP-COMMA-CONFUSION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:31:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00762; Tue, 3 Jan 89 15:30:48 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06046; Tue, 3 Jan 89 15:30:43 MST
Date: Tue, 3 Jan 89 15:30:43 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032230.AA06046@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue SHARP-COMMA-CONFUSION
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: SHARP-COMMA-CONFUSION
References: CLtL p. 356
Issue LOAD-TIME-EVAL
Category: CHANGE
Edit History: V1, 17 Oct 1988, Sandra Loosemore
V2, 30 Dec 1988, Sandra Loosemore (comments from Pitman)
Problem Description:
The way the read macro #, is defined in CLtL does not make it clear
that it can only appear inside of (implicitly) quoted structure to
guarantee consistent handling between the interpreter and the
compiler. Examples of inconsistent uses would be #, forms appearing
outside of a QUOTE that expand into list or symbol forms that could be
interpreted as code, or strings that could be interpreted as
documentation strings. Users are even more likely to be confused
because the wording in CLtL compares the behavior of #, to the special
form EVAL-WHEN, which must appear in a for-evaluation position.
#, also presents a serious problem to program-analyzing programs
because evaluation is tied to the reader, rather than the interpreter
or compiler. In theory, this could be handled by altering the read table
to have #, construct a "magic cookie" instead of performing read-time
evaluation and having the code walker examine quoted structures, but I've
never seen this actually done in practice.
Proposal SHARP-COMMA-CONFUSION:REMOVE:
Remove the #, read macro from the language.
Rationale:
Removing #, is simpler than trying to redefine it. Removing it from
the standard, rather than redefining it to mean something else (see
issue LOAD-TIME-EVAL), would allow implementations to continue to
provide it as an extension. (Although CLtL does not appear to
explicitly address the question of whether implementations may extend
the reader syntax, some implementations already provide sharp-sign
read macros other than those described in CLtL, such as #P syntax for
pathnames.)
Current Practice:
#, is not used very frequently, but the functionality it provides is
important in some advanced applications; one such application that has
been cited is CLOS. Maintainers of such applications have generally
expressed a willingness to give up #, only if a suitable alternative
is offered (see issue LOAD-TIME-EVAL).
PSL/PCLS has never bothered to implement #, correctly (it's treated
just like #.), and nobody has ever complained about it being broken.
Cost to implementors:
None.
Cost to users:
Because #, is used so infrequently, most users would probably not even
notice its absence.
Issue LOAD-TIME-EVAL proposes to add a special form that would provide
a somewhat cleaner mechanism for load-time evaluation.
It is also possible to use a global variable to get the similar effect as
#,, although this is sometimes awkward and carries a space and
performance penalty in many implementations.
Benefits:
The language specification is simplified by removing a peculiar
feature of the language that is accessible only through the reader.
Removing #, may also allow simpler strategies for implementing
compiled file loaders to be used.
Discussion:
If this proposal is rejected, the definition of #, in the standard will
still need to be clarified to indicate that #, can only appear in
quoted structure. It should probably also include some mention of the
problems that #, can cause code walkers.
Kent Pitman says:
I approve of the ideas being discussed, but ONLY contingent on
LOAD-TIME-VALUE being introduced.
I am optimistic that LOAD-TIME-EVAL will pass, and so I don't think this
will keep #, from passing, but:
- I want people who vote for this to realize the importance of voting
for LOAD-TIME-EVAL.
- On the off chance LOAD-TIME-EVAL doesn't pass, I want people to have
been warned that the consequences were severe for some major
applications.
- I want the records to reflect the actual rationale people should and
hopefully will be using to make these decisions.
∂03-Jan-89 1429 X3J13-mailer issue LOAD-TIME-EVAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:29:40 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00654; Tue, 3 Jan 89 15:28:33 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06041; Tue, 3 Jan 89 15:28:30 MST
Date: Tue, 3 Jan 89 15:28:30 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032228.AA06041@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue LOAD-TIME-EVAL
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: LOAD-TIME-EVAL
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
issue SHARP-COMMA-CONFUSION
Category: ADDITION
Edit history: 06-Jun-87, Version 1 by James Kempf
17-Jul-87, Version 2 by James Kempf
12-Nov-87, Version 3 by Pitman (alternate direction)
01-Feb-88, Version 4 by Moon
(from version 2 w/ edits suggested by Masinter)
06-Jun-88, Version 5 by Pitman
(fairly major overhaul, merging versions 3 and 4)
21-Sep-88, Version 6 by Moon (stripped down)
17-Oct-88, Version 7 by Loosemore (change direction again)
30-Dec-88, Version 8 by Loosemore (tweaks)
Problem description:
Common Lisp provides reader syntax (#,) which allows the programmer
to designate that a particular expression within a program is to be
evaluated early (at load time) but to later be treated as a constant.
Unfortunately, no access to this capability is available to programs
which construct other programs without going through the reader.
Some computations can be deferred until load time by use of EVAL-WHEN,
but since EVAL-WHEN must occur only at toplevel, and since the nesting
behavior of EVAL-WHEN is quite unintuitive, EVAL-WHEN is not a general
solution to the problem of load-time computation of program constants.
Proposal (LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM):
Add a new special form, LOAD-TIME-VALUE, which has the following
contract:
LOAD-TIME-VALUE form &optional read-only-p [Special Form]
LOAD-TIME-VALUE provides a mechanism for delaying evaluation of <form>
until the expression is in the "runtime" environment.
If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
performs normal semantic processing such as macro expansion but
arranges for the evaluation of <form> to occur at load time in a null
lexical environment, with the result of this evaluation then being
treated as an immediate quantity at run time. It is guaranteed that
the evaluation of <form> will take place only once when the file is
loaded, but the order of evaluation with respect to the "evaluation"
of top-level forms in the file is unspecified.
If a LOAD-TIME-VALUE expression appears within a function compiled
with COMPILE, the <form> is evaluated at compile time in a null lexical
environment. The result of this compile-time evaluation is treated as
an immediate quantity in the compiled code.
In interpreted code, (LOAD-TIME-VALUE <form>) is equivalent to (VALUES
(EVAL (QUOTE <form>))). Implementations which implicitly compile
(or partially compile) expressions passed to EVAL may evaluate the
<form> only once, at the time this compilation is performed. This is
intentionally similar to the freedom which implementations are given
for the time of expanding macros in interpreted code.
Note that, in interpreted code, there is no guarantee as to when
evaluation of <form> will take place, or the number of times the
evaluation will be performed. Since successive evaluations of the
same LOAD-TIME-VALUE expression may or may not result in an evaluation
which returns a "fresh" object, destructive side-effects to the
resulting object may or may not persist from one evaluation to the
next. It is safest to explicitly initialize the object returned by
LOAD-TIME-VALUE, if it is later modified destructively.
Implementations must guarantee that each reference to a
LOAD-TIME-VALUE expression results in at least one evaluation of its
nested <form>. For example,
(CONS #1=(LOAD-TIME-VALUE (COMPUTE-IT)) #1#)
must perform two calls to COMPUTE-IT; although there is only one
unique LOAD-TIME-VALUE expression, there are two distinct references
to it.
In the case of a LOAD-TIME-VALUE form appearing in a quoted expression
passed to EVAL, each call to EVAL must result in a new evaluation of
<form>. For example,
(DEFVAR X 0)
(DEFUN FOO () (EVAL '(LOAD-TIME-VALUE (INCF X))))
is guaranteed to increment X each time FOO is called, while
(DEFUN FOO () (LOAD-TIME-VALUE (INCF X)))
may cause X to be evaluated only once.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL (the default), the result must be considered
ordinary, modifiable data. If T, the result is a read-only quantity
which may, as appropriate, be copied into read-only space and/or shared
with other programs. (Because this is a special form, this argument is
-not- evaluated and only the literal symbols T and NIL are permitted.)
Rationale:
LOAD-TIME-VALUE is a special form rather than a function or macro
because it requires special handling by the compiler.
Requiring the compiler to perform semantic processing such as macro
expansion on the nested <form>, rather than delaying all such processing
until load time, has the advantages that fewer macro libraries may need
to be available at load time, and that loading may be faster and result
in less consing due to macroexpansion. If users really want to delay
macroexpansion to load time, this can be done with an explicit call to
EVAL, e.g.
(LOAD-TIME-VALUE (EVAL '(MY-MACRO)))
Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
evaluated more than once makes simplifies its implementation in
interpreters which do not perform a preprocessing code walk. It also
makes the rules for the time of its processing analogous to those
for macro expansion.
This proposal explicitly does -not- tie LOAD-TIME-VALUE to the #,
read macro. Doing so would be an incompatible change to the definition
of #, (which is reliably useful only -inside- quoted structure,
while LOAD-TIME-VALUE must appear -outside- quoted structure in a
for-evaluation position).
The requirement that LOAD-TIME-VALUE expressions be evaluated once per
reference (rather than once per unique expression) prevents problems
that could result by performing destructive side-effects on a value
that is unexpectedly referenced in more than one place.
Current Practice:
This is an addition to the language and has not yet been implemented.
Cost to Implementors:
In compiled code, (LOAD-TIME-VALUE <form>) is similar to
'#,<form>. Most implementations can probably make use of the same
mechanism they use to handle #, to handle LOAD-TIME-VALUE. Note that
#, does not currently provide a mechanism for dealing with
non-read-only-ness.
Implementing LOAD-TIME-VALUE in the interpreter should be fairly
straightforward, since one simply needs to evaluate the <form> in the
null lexical environment. Implementations that use a preprocessing
code walk in the interpreter to perform macro expansion could process
LOAD-TIME-VALUE forms at that time.
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Cost to Users:
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Benefits:
Users are given a mechanism that to force evaluation to be delayed
until load time that does not rely on a feature of the reader.
Discussion:
Earlier versions (up to version 7) of this proposal stated that
all semantic processing of the LOAD-TIME-VALUE form should be postponed
until load time.
The semantics of LOAD-TIME-VALUE would be simplified considerably if
the READ-ONLY-P argument were removed and destructive operations on
the result of evaluating <form> prohibited. However, some people feel
that the ability to destructively modify the value is an essential
feature to include.
"Collapsing" of multiple references to the same LOAD-TIME-VALUE
expression could be allowed for read-only situations, but it seems
like it would be more confusing to make it legal in some situations
and not in others.
A number of other alternatives have been considered on this issue,
including:
- A proposal for a new special form that would force evaluation of
the <form> to happen only once. This was rejected because of
implementation difficulties.
- A proposal to add a function making the "magic cookie" used by #,
available to user code. The current proposal does not prevent such
a function from being added, but this approach appeared to have
less support than making the hook available as a new special form.
- A proposal to remove #, entirely (issue SHARP-COMMA-CONFUSION).
- A suggestion to change the behavior of (EVAL-WHEN (LOAD) ...).
Kent Pitman says:
Although I'm willing to take multiple evaluation in the interpreter
as a compromise position, I would like it mentioned in the discussion
that this was only an expedient to getting this issue accepted at all,
and that I'm not really happy about it. I have said that I think a
number of our lingering problems (with EVAL-WHEN, COMPILER-LET, and
this -- for example) are due to the presence of interpreters which do
not do a semantic-prepass at a known time. If I had my way, we would
require a semantic pre-pass and we would then be able to forbid
multiple evaluations even in the interpreter.
∂05-Jan-89 1342 X3J13-mailer ISO discussion and X3J13 Agenda DRAFT
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Jan 89 13:42:22 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA05813g; Thu, 5 Jan 89 13:38:32 PST
Received: by challenger id AA12199g; Thu, 5 Jan 89 13:34:30 PST
Date: Thu, 5 Jan 89 13:34:30 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901052134.AA12199@challenger>
To: x3j13@sail.stanford.edu
Subject: ISO discussion and X3J13 Agenda DRAFT
Monday, January 16
8:00am - ISO discussion, Chart room
We've found copying facilities to be very expensive at hotels. We intend not
to use their facilities. Please mail copies of reports to Liz Anne's
attention at the hotel if you intend to distribute reports at the meeting.
Participants are encouraged to bring copies of reports mailed to them to the
meeting.
X3J13 Committee Meeting Agenda DRAFT
January 16 - 18, 1988
1 Call to Order, January 16, 9:00am Chart Room
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Character Subcommittee Report, Thom Linden (2 hours)
7 Coffee Break 10:30
8 Character continuation
9 Chapter 3 CLOS, Gregor Kiczales (1 hour)
10 LUNCH 12:00 Voyage Room Restaurant
11 Compiler Subcommittee, Sandra Loosemore (2 hours)
12 Iteration Subcommittee Report, Jonl White (30 minutes) 89-004
13 Recess 3:00
14 Call to Order, 8:00pm
15 Other Subcommittee Reports
16 Recess 10:00
17 Call to Order, January 17, 9:00am Chart Room
18 Other Subcommittee Reports
19 Coffee Break 10:30am
20 Cleanup Subcommittee, Larry Masinter
21 Lunch 12:00 Voyage Room Restaurant
22 Cleanup continuation
23 Break 3:00
24 Cleanup continuation
25 Recess 4:30pm
26 Luau 6:45pm
27 Call to Order, January, 18 9:00am Paddle Room
28 Cleanup continuation
29 Coffee Break 10:30
30 Cleanup continuation
31 Lunch, 12:00 Voyage Room Restaurant
32 Cleanup continuation
33 Recess, 3:00pm
34 Call to Order, January, 18 7:00pm
35 Cleanup continuation
36 Adjournment
* Monday 8:00 - ISO discussion
Not part of X3J13 Committee Meeting
∂06-Jan-89 1504 X3J13-mailer Ballots, please
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:04:38 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 00:23:39 PST
Date: 6 Jan 89 00:23 PST
From: masinter.pa@Xerox.COM
Subject: Ballots, please
To: X3J13@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
Message-ID: <890106-002339-193@Xerox>
We've gotten very few ballots back. Please let us know soon if you plan to
vote even if you can't get your ballot in right away; we'll need some time
to respond to some of the comments and prepare new versions for the
meeting!
Thanks,
Larry
∂06-Jan-89 2253 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:52:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 22:51:48 PST
Date: 6 Jan 89 22:51 PST
From: masinter.pa@Xerox.COM
To: X3J13@Sail.Stanford.Edu
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890106-225148-2007@Xerox>
This issue will be voted separately at the X3J13 meeting.
I (unfortunately) caused some controversy by changing the
sense of the proposal at the last minute. I'm sorry, as I do
not feel stringly about this issue, although there are some
additional considerations. I've included some, but not all,
Additional Comments at the end.
This version has two proposals, both the ALLOW proposal
which I introduced with version 8 and a LEXICAL proposal.
The difference is about whether a type declaration affects only variable
references within its scope, or also affects variable references that
are outside the scope of the declaration but dynamically inside the
execution of a form that is itself inside the scope of the declaration.
This really has nothing to do with the original goal of the proposal,
since exactly the same issue arises for a type declaration attached
to a binding of a special variable.
If you've yet to complete your ballot, please indicate which
version of the proposal you're votes apply to.
!
Forum: Cleanup
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Related issues: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
DECLARATION-SCOPE
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Version 5, 30-Sep-88, Masinter (cost to implementors)
Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
Version 7, 5-Dec-88, Masinter (scope->extent)
Version 8, 7-Dec-88, Masinter (back to scope)
Version 9, 2-Jan-89, Moon (2 proposals, to clarify discussion)
Problem description:
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
any effect:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
(incf y)
...random algorithm...))
Proposal (DECLARE-TYPE-FREE:ALLOW):
Specify that a type declaration does not only "affect variable bindings";
rather, type declarations are legal in all declarations. The interpretation
of a type declaration is that, during the execution of any expression
within the scope of the declaration, it is an error for the value of
the declared variable not to be of the declared type. For declarations
that are associated with variable bindings, the type declaration also
applies to the initial binding of the variable. In the special case
of a declaration for which there are no executable expressions
within the scope of the declaration (e.g., (locally (declare (integer x)))),
the result is as if there were executable expressions.
In this proposal, a type declaration affects not only variable
references within its scope, but also affects variable references that
are outside the scope of the declaration but dynamically inside the
execution of a form that is itself inside the scope of the
declaration. Such references can exist when the variable is SPECIAL
or when the declaration is not attached to the variable's binding, so
that the scope of the declaration does not include the entire scope
of the variable.
Proposal (DECLARE-TYPE-FREE:LEXICAL):
Specify that a type declaration does not only "affect variable bindings";
rather, type declarations are legal in all declarations. The interpretation
of a type declaration is that, during the execution of any reference to the
declared variable within the scope of the declaration, it is an error for
the value of the declared variable not to be of the declared type; and
during the execution of any SETQ of the declared variable within the scope
of the declaration, it is an error for the newly assigned value of the
declared variable not to be of the declared type; and at the moment the
scope of the declaration is entered, it is an error for the value of the
declared variable not to be of the declared type.
In this proposal, a type declaration affects only variable references within
its scope, and the meaning of "free" and "variable-binding-associated" type
declarations can be described identically.
This proposal is equivalent to saying that the meaning of a type declaration
is equivalent to changing each reference to <var> within the scope of the
declaration to (THE <type> <var>), changing each expression assigned to the
variable within the scope of the declaration to (THE <type> <new-value>),
and executing (THE <type> <var>) at the moment the scope of the declaration
is entered.
Examples:
;; this is an error under DECLARE-TYPE-FREE:ALLOW:
;; the assertion that x is a fixnum is violated between the two
;; calls to (zap)
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(zap)
x)))
;; this is an error under both proposals
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(print x)
(zap)
x)))
;; this is an error under DECLARE-TYPE-FREE:ALLOW, because
;; the assertion that x is a fixnum
;; is violated during the call to zap, even though few
;; implementations will be able to check:
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL
(let ((x 12) (y 'foo))
(flet ((zap ()
(rotatef x y)
(rotatef x y)))
(locally (declare (fixnum x))
(zap)
x)))
;; this is an error under both proposals, even though the
;; violation of the type constraint happens after the form
;; with the declaration is exited.
(let ((f (let ((x 3))
(declare (fixnum x))
#'(lambda (z) (incf x z)))))
(funcall f 4.3))
Rationale:
This proposal enables optimizing compilers to make use of the otherwise
ignored type information. Many people have often asked for it, and
there is no strong reason to forbid it.
DECLARE-TYPE-FREE:ALLOW is more restrictive on programs and hence allows
more freedom for optimizing compilers. DECLARE-TYPE-FREE:LEXICAL is easier
to understand but allows a specialized representation only where the scope
of the variable is the same as the scope of the declaration or the compiler
can prove that there are no relevant other references to the variable.
Current practice:
Lucid Common Lisp allows "free" type declarations; under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
Implementations that might currently warn about such declarations
would have to remove the warning; otherwise, it is valid to ignore
type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
every reference.
Esthetics:
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
language.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
Documentation might want to discuss the style implications of
nested declarations intersecting. The interesting cases are:
- An inner declaration could be a subtype of an outer one.
This is the most useful case and probably the only one to
be encouraged in code written by humans. e.g.,
(locally (declare (type number x))
(locally (declare (type integer x))
...use X as integer...))
- An outer declaration could be a subtype of an inner one.
This is useless but harmless. It might happen as the result
of certain macro situations. e.g.,
(locally (declare (type integer x))
(locally (declare (type number x))
...use X as integer...))
- Two types may only partially overlap. This would presumably
happen only as the result of a macro expansion.
(locally (declare (type fixnum x))
(locally (declare (type (or bit package) x))
...use X as BIT...))
!
Additional Comments:
"The ALLOW proposal has the problems that:
- It isn't enforceable.
- In exactly those cases where it is enforceable, it's useful to enforce.
In those case where it is not enforceable (the odd middle-ground cases
in the Examples), it doesn't help you any to enforce the restriction, and
it might get in your way.
"
"Btw, both versions 8 and 9 have the non-preemptive problem that the
only examples they provide illustrate what happens in the screw
cases. This might lead some people to think that this whole issue
is kind of random. I think there should be a few examples of the
"normal use" (such as the un-filled-out examples in the problem
description). "
"Suppose I have
(defun frob (delta)
(flet ((more (x) (+ x delta)))
;; if you like, put (declare (inline more)) here
(typecase delta
(float (locally (declare (type float delta))
... (more rho ) ... )
((signed-byte 8)
(locally (declare (type (signed-byte 8) delta))
... (more zz) ... )
...)
Even without the INLINE, it is a common & legal transformation
to do inline substitution on small FLETted functions. Even though
the reference DELTA in the definition of MORE isn't within the
lexical scope of the local declaration, it *is* the same delta. While
its not impossible to maintain a separate contour in order to segregate
the type declarations, it seems like unnecessary work, and in fact, the
declaration is quite useful if MORE is inlined. This is only the case
with the ALLOW proposal and not the LEXICAL proposal."
∂07-Jan-89 0935 X3J13-mailer Issue CONSTANT-MODIFICATION, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 09:35:06 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA19620; Sat, 7 Jan 89 10:33:59 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08864; Sat, 7 Jan 89 10:33:56 MST
Date: Sat, 7 Jan 89 10:33:56 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071733.AA08864@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: Issue CONSTANT-MODIFICATION, version 2
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: CONSTANT-MODIFICATION
References: CLtL p. 78, 87
Issue CONSTANT-COLLAPSING
Category: CLARIFICATION
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 12 Dec 1988, Sandra Loosemore
Problem Description:
CLtL states that an implementation is permitted to "collapse"
constants appearing in code to be compiled if they are EQUAL. This
implicit sharing of compiled data structures may result in
unpredictable behavior if destructive operations are performed.
However, CLtL does not explicitly allow or disallow destructive
operations on constants.
Proposal CONSTANT-MODIFICATION:DISALLOW:
Clarify that it is an error to destructively modify objects which are
self-evaluating forms or which appear inside of a QUOTE special form.
Rationale:
Disallowing modification of constants consistently in all situations,
rather than just in compiled code, is proposed because in some
compiled-only situations it may be difficult to distinguish between
"compiled" and "interpreted" code.
Current Practice:
Many implementations "collapse" compiled constants.
Many implementations treat compiled constants as read-only. In
PSL/PCLS, for example, quoted data structures in compiled code are
copied into a part of memory that is not scanned by the garbage
collector. The TI Explorer's loader also copies constants into a
write-protected memory area.
Cost to implementors:
None.
Cost to users:
User programs which perform destructive operations on constants are
already nonportable.
Benefits:
Many novice programmers do not realize that modifying quoted data
structures is an error in many implementations. Including an explicit
statement in the standard that doing so is a bad idea will reduce
confusion.
Discussion:
The issue of whether implementations are permitted to copy constants
seen by EVAL or COMPILE is discussed separately as issue QUOTE-MAY-COPY.
∂07-Jan-89 0933 X3J13-mailer Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 09:33:34 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA19606; Sat, 7 Jan 89 10:32:25 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08861; Sat, 7 Jan 89 10:32:22 MST
Date: Sat, 7 Jan 89 10:32:22 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071732.AA08861@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 8
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
References: CLtL pages 66-70, 143
Category: CLARIFICATION
Edit history: V1, 07 Oct 1987 Sandra Loosemore
V2, 15 Oct 1987 Sandra Loosemore
V3, 15 Jan 1988 Sandra Loosemore
V4, 06 May 1988 Sandra Loosemore
V5, 20 May 1988 Sandra Loosemore
V6, 09 Jun 1988 Sandra Loosemore
V7, 16 Dec 1988 Sandra Loosemore
(Comments from Pitman, change DEFCONSTANT, etc.)
V8, 31 Dec 1988 Sandra Loosemore
(CLOS additions, etc.)
Problem Description:
Standard programming practices assume that, when calls to defining
macros such as DEFMACRO and DEFVAR are processed by COMPILE-FILE,
certain side-effects occur that affect how subsequent forms in the
file are compiled. However, these side-effects are not mentioned in
CLtL, except for a passing mention that macro definitions must be
``seen'' by the compiler before it can compile calls to those macros
correctly. In order to write portable programs, users must know
exactly which defining macros have compile-time side-effects and what
those side-effects are.
Inter-file compilation dependencies are distinct from, and not
addressed by, this issue.
Proposal: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
(1) Clarify that defining macros such as DEFMACRO or DEFVAR, appearing
within a file being processed by COMPILE-FILE, normally have
compile-time side effects which affect how subsequent forms in the
same file are compiled. A convenient model for explaining how these
side effects happen is that the defining macro expands into one or
more EVAL-WHEN forms, and that the calls which cause the compile-time
side effects to happen appear in the body of an (EVAL-WHEN (COMPILE)
...) form.
(2) The affected defining macros and their specific side effects are
as follows. In each case, it is identified what users must do to
ensure that their programs are conforming, and what compilers must do
in order to correctly process a conforming program.
DEFTYPE: Users must ensure that the body of a DEFTYPE form is
evaluable at compile time if the type is referenced in subsequent type
declarations. The compiler must ensure that the DEFTYPE'd type
specifier is recognized in subsequent type declarations. If the
expansion of a type specifier is not defined fully at compile time
(perhaps because it expands into an unknown type specifier or a
SATISFIES of a named function that isn't defined in the compile-time
environment), an implementation may ignore any references to this type
in declarations and/or signal a warning.
DEFMACRO, DEFINE-MODIFY-MACRO: The compiler must store macro
definitions at compile time, so that occurrences of the macro later on
in the file can be expanded correctly. Users must ensure that the
body of the macro is evaluable at compile time if it is referenced
within the file being compiled.
DEFUN: DEFUN is not required to perform any compile-time side effects.
In particular, DEFUN does not make the function definition available
at compile time. An implementation may choose to store information
about the function for the purposes of compile-time error-checking
(such as checking the number of arguments on calls), or to enable the
function to be expanded inline.
DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
named by these forms have been proclaimed special. However, it must
not evaluate the initial value form or SETQ the variable at compile
time.
DEFCONSTANT: The compiler must recognize that the symbol names a
constant. An implementation may choose to evaluate the value-form at
compile time, load time, or both. Therefore users must ensure that
the value-form is evaluable at compile time (regardless of whether or
not references to the constant appear in the file) and that it always
evaluates to the same value.
DEFSETF, DEFINE-SETF-METHOD: The compiler must make SETF methods
available so that it may be used to expand calls to SETF later on in
the file. Users must ensure that the body of DEFINE-SETF-METHOD and
the complex form of DEFSETF are evaluable at compile time if the
corresponding place is referred to in a subsequent SETF in the same
file. The compiler must make these SETF methods available to
compile-time calls to GET-SETF-METHOD when its environment argument is
a value received as the &ENVIRONMENT parameter of a macro.
DEFSTRUCT: The compiler must make the structure type name recognized
as a valid type name in subsequent declarations (as for DEFTYPE) and
make the structure slot accessors known to SETF. In addition, the
compiler must save enough information about the structure type so that
further DEFSTRUCT definitions can :INCLUDE a structure type defined
earlier in the file being compiled. The functions which DEFSTRUCT
generates are not defined in the compile time environment, although
the compiler may save enough information about the functions to code
subsequent calls inline. The #S reader syntax may or may not be
available at compile time.
DEFINE-CONDITION: The rules are essentially the same as those for
DEFSTRUCT; the compiler must make the condition type recognizable as a
valid type name, and it must be possible to reference the condition
type as the parent-type of another condition type in a subsequent
DEFINE-CONDITION in the file being compiled.
DEFCLASS: The compiler must make the class name be recognized as a
valid type name in subsequent declarations (as for DEFTYPE) and be
recognized as a valid class name for DEFMETHOD parameter
specializers and for use as the :METACLASS option of a subsequent
DEFCLASS. The compiler must make the class definition available to
be returned by FIND-CLASS when its environment argument is a value
received as the &ENVIRONMENT parameter of a macro.
DEFGENERIC and DEFMETHOD: These are not required to perform any
compile-time side effects. In particular, the methods are not
installed for invocation during compilation. An implementation may
choose to store information about the generic function for the
purposes of compile-time error-checking (such as checking the number
of arguments on calls, or noting that a definition for the function
name has been seen).
DEFINE-METHOD-COMBINATION: The compiler is not required to perform
any compile-time side-effects.
DEFPACKAGE: All of the actions normally performed by this macro at load
time must also be performed at compile time.
(3) The compile-time side effects may cause information about the
definition to be stored differently than if the defining macro had
been processed in the "normal" way (either interpretively or by loading
the compiled file).
In particular, the information stored by the defining macros at
compile time may or may not be available to the interpreter (either
during or after compilation), or during subsequent calls to COMPILE or
COMPILE-FILE. For example, the following code is nonportable because
it assumes that the compiler stores the macro definition of FOO where
it is available to the interpreter:
(defmacro foo (x) `(car ,x))
(eval-when (eval compile load)
(print (foo '(a b c))))
A portable way to do the same thing would be to include the macro
definition inside the EVAL-WHEN:
(eval-when (eval compile load)
(defmacro foo (x) `(car ,x))
(print (foo '(a b c))))
Rationale:
The proposal generally reflects standard programming practices. The
primary purpose of the proposal is to make an explicit statement that
CL supports the behavior that most programmers expect and many
implementations already provide.
The primary point of controversy on this issue has been the treatment
of the initial value form by DEFCONSTANT, where there is considerable
variance between implementations. The effect of the current wording is
to legitimize all of the variants.
Current Practice:
Many (probably most) Common Lisp implementations, including VaxLisp
and Lucid Lisp, are already largely in conformance.
In VaxLisp, macro definitions that occur as a side effect of compiling
a DEFMACRO form are available to the compiler (even on subsequent
calls to COMPILE or COMPILE-FILE), but are not available to the
interpreter (even within the file being compiled).
By default, Kyoto Common Lisp evaluates *all* top level forms as they
are compiled, which is clearly in violation of the behavior specified
on p 69-70 of CLtL. There is a flag to disable the compile-time
evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do not make
their definitions available at compile-time either.
Cost to implementors:
The intent of the proposal is specifically not to require the compiler
to have special knowledge about each of these macros. In
implementations whose compilers do not treat these macros as special
forms, it should be fairly straightforward to use EVAL-WHENs in their
expansions to obtain the desired compile-time side effects.
Cost to users:
Since CLtL does not specify whether and what compile-time side-effects
happen, any user code which relies on them is, strictly speaking,
nonportable. In practice, however, most programmers already expect
most of the behavior described in this proposal and will not find it
to be an incompatible change.
Benefits:
Adoption of the proposal will provide more definite guidelines on how
to write programs that will compile correctly under all CL
implementations.
Discussion:
Reaction to a preliminary version of this proposal on the common-lisp
mailing list was overwhelmingly positive. More than one person
responded with comments to the effect of "but doesn't CLtL already
*say* that somewhere?!?" Others have since expressed a more lukewarm
approval.
It has been suggested that this proposal should also include PROCLAIM.
However, since PROCLAIM is not a macro, its compile-time side effects
cannot be handled using the EVAL-WHEN mechanism. A separate proposal
seems more appropriate.
Item (3) allows for significant deviations between implementations.
While there is some sentiment to the effect that the compiler should
store definitions in a manner identical to that of the interpreter,
other people believe strongly that compiler side-effects should be
completely invisible to the interpreter. The author is of the opinion
that since this is a controversial issue, further attempts to restrict
this behavior should be considered as separate proposals.
It should be noted that user-written code-analysis programs must
generally treat these defining macros as special forms and perform
similar "compile-time" actions in order to correctly process
conforming programs.
∂07-Jan-89 0946 X3J13-mailer **DRAFT** Issue COMPILER-VERBOSITY, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 09:46:19 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA19738; Sat, 7 Jan 89 10:45:11 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08872; Sat, 7 Jan 89 10:45:08 MST
Date: Sat, 7 Jan 89 10:45:08 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071745.AA08872@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** Issue COMPILER-VERBOSITY, version 5
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILER-VERBOSITY
References: CLtL p. 438-329; 426
issue COMPILER-DIAGNOSTICS
Category: CHANGE/CLARIFICATION/ENHANCEMENT
Edit History: V1, 25 Oct 1988, Sandra Loosemore
V2, 12 Dec 1988, Dan L. Pierson (add USE-CONDITIONS)
V3, 15 Dec 1988, Dan L. Pierson (expand on conditions)
V4, 21 Dec 1988, Dan L. Pierson (reword and clarify)
V5, 06 Jan 1989, Sandra Loosemore (update discussion)
Status: **DRAFT**
Problem Description:
Implementations vary widely in the amount of information that is printed
out by COMPILE-FILE. In some situations, it would be useful to control
how much information is printed.
Proposal COMPILER-VERBOSITY:LIKE-LOAD:
Introduce a special variable, *COMPILE-VERBOSE*, with an implementation-
dependent initial value.
Add :VERBOSE and :PRINT keyword arguments to the function COMPILE-FILE,
analogous to those for the function LOAD.
The :VERBOSE argument (which defaults to the value of *COMPILE-VERBOSE*),
if true, permits COMPILE-FILE to print a message in the form of a comment
to *STANDARD-OUTPUT* indicating what file is being compiled and other
useful information.
The :PRINT argument (which defaults to NIL), if true, causes
information about top-level forms in the file being compiled to be
printed to *STANDARD-OUTPUT*. Exactly what is printed will vary from
implementation to implementation, but nevertheless some information
will be printed.
Rationale:
This proposal makes COMPILE-FILE behave like LOAD. There is already
some precedent for doing this (for example, issue COMPILE-FILE-PACKAGE,
which makes COMPILE-FILE as well as LOAD rebind *PACKAGE*).
Current Practice:
Lucid provides a :MESSAGES keyword argument to COMPILE-FILE, which can
either be a stream to send progress messages to, or NIL to suppress messages.
The default value is T, which sends messages to "the standard terminal
device".
On the TI Explorer, COMPILE-FILE displays the name of the function being
compiled when the option :VERBOSE T is given or special variable
COMPILER:COMPILER-VERBOSE is true. (In other words, they use :VERBOSE
to mean what this proposal says to use :PRINT for.)
Cost to implementors:
This is an incompatible change for some implementations. While the
changes required should be conceptually simple, their implementation
may involve a significant amount of grunt work. At least two
implementations already provide some similar mechanism for suppressing
messages.
Cost to users:
Some (non-portable) user code may break in implementations where this is
an incompatible change.
Specifying that the :PRINT argument defaults to NIL is consistent with
LOAD, but in most implementations the default now is to print out a
lot of information about each function or top-level form. Some users
may find it irritating to have to type in :print t to get the same
amount of information they're used to seeing.
Benefits:
Users are given a portable way to control how much information is printed
by COMPILE-FILE.
Proposal COMPILER-VERBOSITY:USE-CONDITIONS:
Add the new subtype of CONDITION, NOTICE, defined in
COMPILER-DIAGNOSTICS (V5). Add a new subtype of NOTICE, INFO.
Require compilers to "print" all messages covered by this proposal by
using the function NOTICE to signal a condition of type INFO instead
of directly writing the message. For the purposes of this proposal
"compilers" refers to both COMPILE and COMPILE-FILE.
Note that, since a compiler is never required to print any messages
covered by this proposal, no portable program may assume that any
conditions of type INFO will actually be signalled.
Rationale:
This allows informational compiler messages and compiler diagnostics
to be handled in a uniform manner with a simple, well defined way for
the user to gain any desired degree of control over these messages.
Current Practice:
No one currently controls compiler messages via the condition system.
Cost to implementors:
This is an incompatible change for all implementations. It should be
a conceptually simple change to make once an implementation supports
the condition system, however the actual implementation of the change
may involve a significant amount of grunt work.
All existing implementations can continue support their current
message control interfaces as long as the implementation of their
current interface is changed to comply with this proposal. This could
be done by:
1. Causing the old interface to either establish a condition
handler that accepts messages that shouldn't be printed and
does nothing with them. Note that it would not be legal to
make the handler print the messages that should be printed,
because a user handler must still be given a chance to look at
them.
2. Changing the old interface to conditionally write the message
as it used to, except that NOTICE is used to actually write the
message.
Cost to users:
Some user code may break in implementations which remove any
(non-portable) existing mechanisms to control compiler output.
Benefits:
Users are given a portable way to control how much information is printed
by COMPILE-FILE.
Aesthetics:
Using a well defined, already existing, general mechanism is more
aesthetically pleasing than adding another ad-hoc flag or special
variable.
Discussion:
Rather than just treating :PRINT and :VERBOSE as boolean values, it
might be useful to have them convey more information. For example,
Pitman has suggested using keyword values like :BRIEF or :DETAILED to
allow varying amounts of information of each type to be printed.
Alternatively, it might be reasonable to follow Lucid's precedent to
allow the values of :PRINT and :VERBOSE to be streams to allow
messages to be directed somewhere other than *STANDARD-OUTPUT*.
Either of these suggestions could reasonably be made to apply to LOAD
as well, but the intent of LIKE-LOAD is to make COMPILE-FILE
behave like LOAD, not to change the specification of LOAD.
Loosemore questions whether using conditions for this purpose is
appropriate, because this issue deals with messages indicating the
normal progress of the compiler and conditions are supposed to be used
to signal exceptional (non-ordinary) situations.
Pierson believes that conditions provide a well defined, portable,
non-intrusive interface for user control of infrequent events. While
the use of conditions is not notably efficient, compiler informational
messages are sufficiently infrequent that this should not impose a
noticeable performance penalty.
Pierson would like to see LOAD, etc. changed to also use this
interface.
The two proposals are not mutually incompatible in that the LIKE-LOAD
keywords can be added to an implementation whether or not it is based
on USE-CONDITIONS.
∂07-Jan-89 0944 X3J13-mailer **DRAFT** Issue COMPILER-DIAGNOSTICS, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 09:44:40 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA19722; Sat, 7 Jan 89 10:43:32 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08867; Sat, 7 Jan 89 10:43:26 MST
Date: Sat, 7 Jan 89 10:43:26 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071743.AA08867@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** Issue COMPILER-DIAGNOSTICS, version 8
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILER-DIAGNOSTICS
References: CLtL p. 438-439, 62, 69, 160, 161
Condition System, Revision #18
S:>KMP>cl-conditions.text.34
Issue GC-MESSAGES
Issue RETURN-VALUES-UNSPECIFIED
Issue COMPILER-VERBOSITY
Category: CLARIFICATION, ENHANCEMENT
Edit History: V1, 15 Oct 1988, Sandra Loosemore
V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)
V4, 01 Nov 1988, Sandra Loosemore (fix typos)
V5, 15 Dec 1988, Dan L. Pierson (new condition types)
V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)
V7, 16 Dec 1988, Dan L. Pierson (minor cleanup)
V8, 07 Jan 1989, Sandra Loosemore (expand discussion)
Status: **DRAFT**
Problem Description:
It is unclear whether various diagnostics issued by the compiler are
supposed to be true errors and warnings, or merely messages.
In some implementations, COMPILE-FILE handles even serious error
situations (such as syntax errors) by printing a message and then
trying to recover and continue compiling the rest of the file, rather
than by signalling an error. While this user interface style is just
as acceptable as invoking the debugger, it means that a normal return
from COMPILE-FILE does not necessarily imply that the file was
successfully compiled.
Many compilers issue warnings about programming style issues (such as
binding a variable that is never used but not declared IGNORE).
Sometimes these messages obscure warnings about more serious problems,
and there should be some way to differentiate between the two. For
example, it should be possible to suppress the style warnings.
Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the
return value from COMPILE-FILE should be.
Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:
(1) Add the following to the language:
NOTICE [Type]
The notice type is a subtype of CONDITION, disjoint from
WARNING, SEVERE-CONDITION, and SIMPLE-CONDITION. All types of
notices should inherit from this type.
SIMPLE-NOTICE [Type]
Conditions signalled by NOTICE when given a format string as a
first argument are of this type. This is a subtype of NOTICE,
and in implementations supporting multiple inheritance, this
type will also be a subtype of SIMPLE-CONDITION. The init
keywords :FORMAT-STRING and :FORMAT-ARGUMENTS are supported to
initialize the slots, which can be accessed using
SIMPLE-CONDITION-FORMAT-STRING and SIMPLE-CONDITION-FORMAT-ARGUMENTS.
ALERT [Type]
This is a subtype of NOTICE.
NOTICE datum &rest arguments [Function]
This function signals a condition of type NOTICE. The arguments
are interpreted similarly to those for the function WARN; if the
"datum" is a string, then a condition of type SIMPLE-NOTICE will
be signalled.
While the NOTICE is being signalled, this function establishes
the MUFFLE-NOTICE restart for use by a handler to cause the NOTICE
function to return immediately without further action. If no
handlers for the notice condition are found, or if all such
handlers decline, then the condition will be reported to
*ERROR-OUTPUT*.
The value returned by NOTICE is NIL.
MUFFLE-NOTICE [Function]
This function transfers control to the restart named MUFFLE-NOTICE.
If no such restart exists, MUFFLE-NOTICE signals an error of type
CONTROL-ERROR.
(2) Clarify that ERROR, WARNING, and ALERT conditions may be signalled
within COMPILE or COMPILE-FILE, including arbitrary errors which may
occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...)
forms or macro expansion.
Considering only those conditions signalled -by- the compiler (as
opposed to -within- the compiler),
(a) Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
intervention.
Examples:
file open errors
syntax errors
(b) Conditions of type WARNING may be signalled by the compiler in
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine
that a situation that "is an error" would result at runtime.
Examples:
violation of type declarations
SETQ'ing or rebinding a constant defined with DEFCONSTANT
calls to built-in Lisp functions with wrong number of arguments
or malformed keyword argument lists
referencing a variable declared IGNORE
unrecognized declaration specifiers
(c) All other diagnostics issued by the compiler should be conditions
of type ALERT. In particular, this category includes all
diagnostics about matters of programming style. Although
conditions of type ALERT -may- be signalled in these
situations, no implementation is -required- to do so.
However, if an implementation does choose to signal a
condition, that condition will be of type ALERT and will be
signalled by a call to the function NOTICE.
Examples:
redefinition of function with different argument list
unreferenced local variables not declared IGNORE
declaration specifiers described in CLtL but ignored by
the compiler
(3) Require COMPILE-FILE to establish a condition handler. Add a
:HANDLER keyword argument to COMPILE-FILE, which is a user condition
handler function which is to be used during compilation. If the user
handler is not supplied or declines to handle a condition, then the
compiler's default handler will be invoked. Require the compiler
to handle the ABORT restart by aborting the smallest feasible part
of the compilation.
(4) Specify that COMPILE-FILE returns three values. The first value is the
truename of the output file, or NIL if the file could not be created.
The second value is non-NIL if errors were signalled during compilation
that were not handled by the user condition handler (indicating that
the output file is almost certainly unusable). The third value is
non-NIL if warnings were signalled during compilation that were not
handled by the user condition handler (indicating that the output
file may or may not be usable).
(5) Clarify that COMPILE does not establish a condition handler. Instead,
it uses whatever condition handler has been established in the environment
from which it is called.
Rationale:
Point by point,
(1) The new condition types NOTICE and ALERT are structured to allow
this part of the condition hierarchy to be further extended. In
particular, the issue COMPILER-VERBOSITY proposes an additional
subtype of NOTICE named INFO. The description of the NOTICE
function parallels the behavior of WARN.
(2) Conditions such as syntax errors which are errors in the interpreter
remain errors in the compiler. The division of other conditions
into WARNINGs and ALERTs allows potentially serious problems to be
distinguished from mere kibbitzing on the part of the compiler.
(3) It is reasonable for the default handling of compiler errors not to
cause the debugger to be invoked. However, any condition handler
established by COMPILE-FILE would override handlers established by the
user in the surrounding environment.
Requiring the compiler to handle the ABORT restart reflects what
several implementations already do (although probably not using this
mechanism). The intent of the wording is to allow an implementation
to abort the entire file compilation if it is not feasible to abort a
smaller part.
(4) This allows users to determine whether or not COMPILE-FILE is able to
actually compile the file successfully. Returning several values is
is more useful than a single success/failure value because there are
several degrees of failure.
(5) This is to reflect the use of COMPILE-FILE as being more "batch"-oriented
and COMPILE as being more interactive. There is less motivation to have
COMPILE try to recover from errors without user interaction.
Test Case/Example:
An example to illustrate how COMPILE-FILE should set up its condition
handlers is:
(defvar *output-file-truename* nil)
(defvar *errors-detected* nil)
(defvar *warnings-detected* nil)
;;; Call INTERNAL-COMPILE-FILE to do the real work. Note, that function
;;; may set up additional ABORT restarts.
(defun compile-file (input-file &key output-file handler)
(let ((*output-file-truename* nil)
(*errors-detected* nil)
(*warnings-detected* nil))
(with-simple-restart (abort "Abort compilation.")
(handler-bind ((condition #'compile-file-default-handler))
(if handler
(handler-bind ((condition handler))
(internal-compile-file input-file output-file))
(internal-compile-file input-file output-file))))
(values *output-file-truename*
*errors-detected*
*warnings-detected*)))
;;; The default condition handler keeps track of errors and warnings,
;;; and may also perform other implementation-specific actions.
(defun compile-file-default-handler (condition)
(typecase condition
(error
(setq *errors-detected* t)
...)
(warning
(setq *warnings-detected* t)
...)
(alert
...)
))
Current Practice:
No implementation behaves exactly as specified in this proposal.
In VaxLisp, COMPILE-FILE handles most compile-time errors without
invoking the debugger. (It gives up on that top-level form and moves on
to the next one.) Instead of signalling errors or warnings, it simply
prints them out as messages.
In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems. COMPILE-FILE returns the pathname for the output file.
Symbolics Genera usually tries to keep compiling when it encounters errors;
so does Symbolics Cloe.
On the TI Explorer, the compiler tries to catch most errors and turn
them into warnings (except for errors on opening a file), but the user
can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants
to enter the debugger on an error signalled during reading, macro
expansion, or compile-time evaluation. The true name of the output
file is returned as the first value. A second value indicates whether
any errors or warnings were reported.
Cost to implementors:
The cost to implementors is not trivial but not particularly high. This
proposal tries to allow implementations considerable freedom in what
kinds of conditions the compiler must detect and how they are handled,
while still allowing users some reasonably portable ways to deal with
compile-time errors.
Cost to users:
This is a compatible extension. This proposal may cause users to see
some small differences in the user interface to the compiler, but
implementations already vary quite widely in their approaches. Some
users will probably have to make some minor changes to their code.
Adding the new functions and types may cause conflicts with user code
already using those names.
Benefits:
Users are given a way to detect and handle compilation errors, which
would simplify the implementation of portable code-maintenance
utilities. The behavior of the compiler in error situations is made
more uniform across implementations.
Discussion:
The issue of whether the compiler may print normal progress messages
is discussed in detail in a separate issue, COMPILER-VERBOSITY.
The biggest complaint directed against this proposal is that it is much
too complicated.
Kent Pitman suggested an alternate approach:
Specify that COMPILE and COMPILE-FILE return a second value, SUCCESS-P.
Define that compilers are permitted to handle conditions of type ERROR,
turning them into warnings and continuing to compile as appropriate,
but that if an error was turned into a warning so that COMPILE or
COMPILE-FILE could complete its operation, NIL must be returned as the
second value. The normal successful return value would be T.
Loosemore responded:
I'm concerned that besides possibly not being enough to satisfy the
needs of people who are trying to write portable system-building
utilities, this won't do anything to solve the stated problem, namely
how to suppress useless style warning messages.
Some other possible ways of simplifying the proposal include:
- Remove the :HANDLER argument and the requirement that COMPILE-FILE
establish a condition handler and the :HANDLER argument. Continue
to require it to establish an ABORT restart so that user error
handlers established outside the call to COMPILE-FILE can cause
compilation to proceed.
- Put all of the things relating to the NOTICE condition into a
separate proposal, since it's intended to be a more general tool.
- Forget about the NOTICE condition and use STYLE-WARNING (a subtype
of WARNING) instead of ALERT.
Some might wonder why NOTICE is needed instead of just making ALERT a
subtype of WARNING. This is for compatability with other proposed
conditions, notably INFO. While it might be reasonable to say that a
style "warning" is a legitimate WARNING error message, it is really
hard to justify WARNING status for a message like
;;; Starting to compile file foo.
We also contemplated using the name MESSAGE instead of NOTICE, but it
was felt that NOTICE would be less likely to cause conflicts with
existing user code. Another suggestion has been to call the type
NOTIFICATION and the signalling function NOTIFY; some people think
that the name NOTICE might also be too generic.
Pitman says that he would like to require COMPILE-FILE's default
condition handler never to invoke the debugger. I have left that out
of this proposal because it seems like an unnecessary restriction; if
users want to ensure that kind of behavior it is possible to do so by
supplying a user handler. (Of course, the converse is also true.)
Some of the things specified in section 2c as being ALERTS were
described in CLtL as being WARNINGs. There seems to be general
agreement that these things (particularly complaints about unused
variables) are not as serious as other problems described as warnings.
We might consider introducing a COMPILER-CONDITION that can be used in
mixins with the other condition types, so that error handlers can
distinguish between errors signalled by the compiler itself and errors
signalled during macroexpansion or EVAL-WHEN processing. This would
have to wait until the condition system is fully CLOSified.
Possibly NOTICE should write to *STANDARD-OUTPUT*, or even *TRACE-OUTPUT*,
rather than *ERROR-OUTPUT*.
David Gray writes:
This proposal looks good, but there are a couple of little things worrying
me. One is the potentially confusing shift in terminology by which
compiler messages that are conventionally referred to as "warnings", are
now called "alerts", programmer errors are reported as "warnings", and
only what is conventionally called "fatal errors" are reported as "errors".
I don't know what can be done about this, though, since we do want some
down-grading in severity so that the compiler issues a message and continues
for a situation that will signal an error if the compiled code is run.
Probably we just need to be careful how this is documented in order to
minimize confusion.
Another thing is that this doesn't provide a way to suppress style
"warnings" [ALERT conditions] on a local basis. For example, Lisp
Machines have a macro INHIBIT-STYLE-WARNINGS that can be wrapped around a
single form to keep the compiler quiet. I wonder if we might want a
COMPILER-HANDLER-BIND macro for specifying handlers at compile time? This
would be analogous to COMPILER-LET, but it could avoid the problems that
have doomed COMPILER-LET by specifying that the evaluator is free to
ignore it.
∂07-Jan-89 1048 X3J13-mailer issues relating to compiled constants
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:47:59 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20410; Sat, 7 Jan 89 11:46:53 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08916; Sat, 7 Jan 89 11:46:51 MST
Date: Sat, 7 Jan 89 11:46:51 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071846.AA08916@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issues relating to compiled constants
Reply-To: cl-compiler@sail.stanford.edu
Coming up shortly will be drafts of four issues relating to the
semantics of quoted and self-evaluating constants:
CONSTANT-COMPILABLE-TYPES
What kinds of objects are dumpable by COMPILE-FILE? What
attributes of those objects must the compiler preserve?
CONSTANT-CIRCULAR-COMPILATION
Must the compiler correctly handle circular objects? Must it
preserve sharing of substructures?
CONSTANT-COLLAPSING
Should the compiler be allowed to use a more general equivalence
relationship than EQUAL in coalescing constants?
QUOTE-MAY-COPY
May COMPILE and EVAL, as well as COMPILE-FILE, substitute
equivalent copies of quoted objects?
All of these issues are very closely related, and the outcome of one
issue may affect each of the others. I apologize for not having a
single document that presents a unified view of the semantics of
constants, but since each of these subissues have been controversial
in their own right (some have competing proposals) it seemed better
not to try to lump them all together. I am hoping that distributing
these writeups to a larger audience will result in some feedback that
will allow us to narrow down the range of possibilities.
-Sandra
∂07-Jan-89 1049 X3J13-mailer **DRAFT** issue CONSTANT-CIRCULAR-COMPILATION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:49:17 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20434; Sat, 7 Jan 89 11:48:08 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08922; Sat, 7 Jan 89 11:48:05 MST
Date: Sat, 7 Jan 89 11:48:05 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071848.AA08922@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue CONSTANT-CIRCULAR-COMPILATION
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: CONSTANT-CIRCULAR-COMPILATION
References: Issue CONSTANT-COLLAPSING
Issue QUOTE-MAY-COPY
Category: CLARIFICATION, ADDITION
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 14 Nov 1988, Cris Perdue
V3, 12 Dec 1988, Sandra Loosemore (merge versions 1 and 2)
V4, 03 Jan 1989, Sandra Loosemore (add PRESERVE-SHARING-ONLY)
V5, 06 Jan 1989, Sandra Loosemore (minor wording changes)
Status: **DRAFT**
Problem Description:
CLtL does not specify whether constants containing circular or
recursive references may be compiled. It is also not clear whether
the compiler must preserve sharing of EQ substructures; that is, whether
subobjects that are EQ in the source code must remain EQ after being
compiled.
The proposals below apply to COMPILE-FILE, since it must inherently
copy structures. If issue QUOTE-MAY-COPY is resolved in favor of
allowing COMPILE and possibly EVAL to copy structures, the same
constraints would also apply in those situations. [We would also have
to decide upon the scope over which sharing must be detected in such
situations; the minimal scope would be over a single call to EVAL or
COMPILE.]
In the proposals that follow, "preserving EQness" means that
subobjects that are EQ in the source code must remain EQ after being
compiled; that is, things don't get "less EQ" after compilation.
(Note that coalescing of constants implies that things may get "more
EQ".)
Proposal CONSTANT-CIRCULAR-COMPILATION:NO
State that it is an error for an object containing a circular reference to
appear as a constant to be compiled. State that the compiler is not
required to preserve EQness of substructures.
Rationale:
This proposal would not require any existing implementation to change.
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Proposal CONSTANT-CIRCULAR-COMPILATION:PRESERVE-SHARING-ONLY
State that it is an error for an object containing a circular
reference to appear as a constant to be compiled. State that the
compiler is required to preserve EQness of substructures within a file
compiled with COMPILE-FILE.
Rationale:
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Some programs (such as PCL) have come to depend on COMPILE-FILE
preserving the EQness of uninterned symbols, and it is cleaner
to require sharing to be preserved in general instead of making
symbols be a special case. Requiring sharing to be preserved still
allows loaders to build constants bottom-up.
Proposal: CONSTANT-CIRCULAR-COMPILATION:FLAG
Add to the definition of Common Lisp a special variable:
*DUMP-CIRCLE* [Special variable]
State that if the (compile-time) value of *DUMP-CIRCLE* is NIL, it is
an error for an object containing a circular reference to appear as a
constant to be compiled. State that the compiler is required to
preserve EQness of substructures within a file compiled with
COMPILE-FILE when *DUMP-CIRCLE* is non-NIL. (Note that this differs
from *PRINT-CIRCLE*, which is not required to detect sharing.)
The initial value of *DUMP-CIRCLE* is implementation-dependent.
Rationale:
As with *PRINT-CIRCLE* for printing, writing representations of
objects to a stream is much faster if the implementation does not
attempt to support circular, self-recursive, mutually-referential,
etc. substructure.
Current Practice:
A-Lisp preserves EQness of substructures (since it makes an effort to
collapse isomorphic structures) but signals an error if an attempt is
made to compile a circular constant. PSL and Utah Common Lisp both
get stuck in an infinite loop if an attempt is made to compile a
reentrant structure. The TI Explorer compiler is able to reproduce
recursive lists and arrays, but currently hangs in a loop on a
circular list. Lucid and Symbolics can handle circular constants
correctly. Franz uses a flag to control whether or not to attempt to
detect circular constants.
Cost to implementors:
We know of no implementation that would have to change under proposal
NO. For proposal FLAG, some implementations would require sweeping
changes; in some cases a completely different dumper/loader strategy
would have to be implemented. The cost of proposal
PRESERVE-SHARING-ONLY would fall somewhere in between.
Cost to users:
The situation now is that programs which depend upon circularity or
sharing of substructure being preserved by the compiler are already
nonportable. Proposal NO simply formalizes the status quo. Proposal
FLAG would offer users functionality that is currently not portable.
Benefits:
An area of ambiguity in the language is removed.
Discussion:
JonL has argued against proposal CONSTANT-CIRCULAR-COMPILATION:NO, saying
I don't see any performance justification; and even if there were, I'd
look at it with a very jaundiced eye, favoring interpreter/compiler
consistency over nickle-and-dime issues of compiler speed.
Loosemore thinks PRESERVE-SHARING-ONLY is the "right" solution, but
would also support CONSTANT-CIRCULAR-COMPILATION:NO because it is the
most consistent with current practice -- no implementations would be
required to change and no currently portable programs would be
invalidated. While one could make an argument for this proposal on
the basis of improving compiler speed, the compatibility issue is seen
as far more important.
There was also quite a bit of discussion about how this proposal
relates to the requirement in CLtL (p. 69) about preserving the
EQLness of references to symbolic constants.
∂07-Jan-89 1050 X3J13-mailer **DRAFT** issue CONSTANT-COLLAPSING
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:50:03 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20460; Sat, 7 Jan 89 11:48:54 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08925; Sat, 7 Jan 89 11:48:52 MST
Date: Sat, 7 Jan 89 11:48:52 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071848.AA08925@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue CONSTANT-COLLAPSING
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: CONSTANT-COLLAPSING
References: CLtL p. 78, 87
Issue CONSTANT-MODIFICATION
Issue CONSTANT-COMPILABLE-TYPES
Issue EQUAL-STRUCTURE
Issue QUOTE-MAY-COPY
Category: CHANGE
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 12 Dec 1988, Sandra Loosemore
V3, 03 Jan 1989, Sandra Loosemore
V4, 06 Jan 1989, Sandra Loosemore
Status: **DRAFT**
Problem Description:
CLtL states that an implementation is permitted to "collapse" or
coalesce constants appearing in code to be compiled if they are EQUAL.
The definition of EQUAL does not permit coalescing of more general
isomorphic data structures (such as arrays and structures), which is
often desirable.
Issue QUOTE-MAY-COPY deals with whether coalescing may be performed
only by COMPILE-FILE, or by COMPILE and EVAL as well. CLtL says: "An
object is considered to be a constant in code to be compiled if it is
a self-evaluating form or contained in a QUOTE form".
Proposal CONSTANT-COLLAPSING:GENERALIZE:
State the an implementation is permitted to "collapse" constants
appearing in code to be compiled if they are equivalent under the
relationship specified in issue CONSTANT-COMPILABLE-TYPES.
Rationale:
There is little reason why implementations should not be allowed to
perform more general collapsing of structures, since the arguments
against doing so also apply to collapsing of EQUAL structures, which
is already permitted.
Current Practice:
Both PSL/PCLS and A-Lisp collapse isomorphic arrays and structures,
and certain other data types that are defined internally as structures
(RANDOM-STATEs, for example). Lucid Common Lisp also uses a more
general coalescing predicate than EQUAL.
Cost to implementors:
None. This extends the range of permitted behavior for
implementations but does not require any implementation to change.
Cost to users:
It is hard to imagine a program that would break under this proposal.
Benefits:
Collapsing of isomorphic arrays and structures may lead to significant
memory savings in some applications.
Discussion:
This proposal depends heavily on issue CONSTANT-COMPILABLE-TYPES.
Some people believe that if the definition of EQUAL weren't "broken",
there wouldn't be any need for this proposal.
There is no inherent reason why the "coalescing predicate" must be the
same as the relationship used by the compiler/loader to construct
equivalent copies of objects of constants, but making the same rules
be applied in both situations simplifies the language somewhat.
∂07-Jan-89 1050 X3J13-mailer **DRAFT** issue QUOTE-MAY-COPY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:50:37 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20465; Sat, 7 Jan 89 11:49:27 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08928; Sat, 7 Jan 89 11:49:24 MST
Date: Sat, 7 Jan 89 11:49:24 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071849.AA08928@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue QUOTE-MAY-COPY
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: QUOTE-MAY-COPY
References: CLtL p. 55, 78, 86, 143
Issue CONSTANT-COLLAPSING
Issue CONSTANT-COMPILABLE-TYPES
Issue CONSTANT-MODIFICATION
Category: CHANGE/CLARIFICATION
Edit History: V1, 5 Dec 1988, Sandra Loosemore
V2, 10 Dec 1988, Sandra Loosemore
(comments from Dalton, JonL)
V3, 3 Jan 1989, Sandra Loosemore
(comments from Pitman et al)
V4, 7 Jan 1989, Sandra Loosemore
(update discussion)
Status: **DRAFT**
Problem Description:
May QUOTE return a copy of its argument? In particular, is it
permissible for COMPILE to copy quoted constants to read-only
memory, or to coalesce equivalent constants?
In spite of the name of this issue, the question is not whether QUOTE
itself may copy objects, but whether the semantics of "quoted objects"
is such that it is permissible for the compiler or interpreter to
substitute a copy of the original object.
Background:
CLtL p. 86 states that (QUOTE <x>) simply returns <x>. On
p. 55 it is mentioned that the only self-evaluating forms that may
be copied are numbers or characters. It is also stated that an
implementation is permitted to collapse (or coalesce) EQUAL constants
appearing in code to be compiled.
Because of its nature as a file processor, COMPILE-FILE generally must
cause copies of constants to be constructed when the compiled code is
loaded. In a number of existing Lisp implementations, COMPILE also
causes constant objects to be copied and/or coalesced. Since it is
permissible for an implementation to implicitly compile even
"interpreted" code (p. 143), the semantics of constants seen by EVAL
may also be affected if the in-memory compiler (as well as the file
compiler) is allowed to copy or coalesce constants.
The arguments for allowing constants to be copied can be summarized
briefly as follows. Copying constants to read-only memory can result
in less work for garbage collectors. If there is hardware support for
write-protection of memory, this may also be used to cause an error to
be signalled if an attempt is made to modify the constant. Coalescing
equivalent constants can lead to significant memory savings in some
applications (although this savings is likely to be less for individual
functions compiled with COMPILE than entire programs compiled with
COMPILE-FILE).
The primary argument against allowing constants to be copied or
coalesced is that doing so causes information to be lost, and in the
case of COMPILE and EVAL, there is no inherent reason why this
information must be discarded. Some people also feel that allowing
QUOTE not to return a value that is EQ (or even EQL) to its argument
would be a substantial, incompatible change from its "traditional"
semantics.
Proposal QUOTE-MAY-COPY:ALWAYS:
Change the description of QUOTE to indicate that (QUOTE <x>) returns
an object equivalent to <x>, which may or may not be EQ to <x>.
Likewise, a self-evaluating form may also return an equivalent copy
of the object.
The equivalence relationship is defined in the writeup for issue
CONSTANT-COMPILABLE-TYPES, and only those objects for which this
relationship is defined may appear as quoted or self-evaluating
constants. The restrictions placed on compiled constants in
issue CONSTANT-CIRCULAR-COMPILATION apply to constants in code
processed by EVAL and COMPILE, as well as COMPILE-FILE. EVAL and
COMPILE may also coalesce constants, as described in issue
CONSTANT-COLLAPSING.
If an implementation chooses to copy constants, the copying may only
happen once each time the form containing the constant is processed
with COMPILE or EVAL (see examples below).
Rationale:
This proposal would make the treatment of constants uniform across
COMPILE-FILE, COMPILE, and EVAL.
Proposal QUOTE-MAY-COPY:NOT-EVAL-OR-COMPILE:
Clarify that self-evaluating forms and quoted constants always
evaluate to objects that are EQL to the original, except in the case
of code compiled with COMPILE-FILE (where an equivalent but possibly
non-EQL object is returned). The restrictions on compiling constants
in issues CONSTANT-COMPILABLE-TYPES and CONSTANT-CIRCULAR-COMPILATION
apply only to COMPILE-FILE. Only COMPILE-FILE may coalesce constants
(issue CONSTANT-COLLAPSING).
Rationale:
This proposal is the most consistent with the semantics described in
CLtL. It would make the treatment of constants uniform across
COMPILE and EVAL.
Proposal QUOTE-MAY-COPY:NOT-EVAL:
Clarify that quoted or self-evaluating constants appearing in code
processed by EVAL must return an object that is EQL to the original.
In functions that have been compiled with COMPILE or code that has
been compiled with COMPILE-FILE, an equivalent (but possibly
non-EQL) copy of the object may be returned instead.
The equivalence relationship is defined in the writeup for issue
CONSTANT-COMPILABLE-TYPES, and only those objects for which this
relationship is defined may appear as quoted or self-evaluating
constants in code to be compiled. The restrictions on constants
described in issue CONSTANT-CIRCULAR-COMPILATION apply to both
COMPILE-FILE and COMPILE, and both may coalesce constants as
described in issue CONSTANT-COLLAPSING. There are no restrictions
on what kinds of objects may appear in code processed with EVAL, and
EVAL may not coalesce equivalent constants.
If an implementation chooses to copy constants, the copying may only
happen once each time the form containing the constant is processed
with COMPILE (see examples below).
Rationale:
This proposal is the most consistent with current practice.
Test Cases/Examples:
#1: (Behavior of COMPILE)
Suppose the function FOO is defined:
(defun foo () '(a b c))
Under all three proposals, multiple calls to FOO must always return
EQ values, regardless of whether FOO is interpreted or compiled:
(eq (foo) (foo)) ==> true
Proposals ALWAYS and NOT-EVAL allow FOO to return a "different" EQ
value after it is compiled:
(setq old-foo (foo))
(compile 'foo)
(eq old-foo (foo)) ==> ??? under ALWAYS or NOT-EVAL
true under NOT-EVAL-OR-COMPILE
#2: (Behavior of EVAL)
(let ((x '(a b c)))
(eq x
(eval (list 'quote x))))
Under proposal ALWAYS, this may or may not return true. Proposals
NOT-EVAL-OR-COMPILE and NOT-EVAL guarantee this to return true.
(let ((x '(a b c)))
(eq (eval (list 'quote x))
(eval (list 'quote x))))
Under proposal ALWAYS, this may or may not return true (each call to
EVAL may construct its own copy of X). Proposals NOT-EVAL-OR-COMPILE
and NOT-EVAL guarantee this to return true.
Current Practice:
Implementations in which COMPILE copies constants include PSL/PCLS and
Kyoto Common Lisp. In Lucid Common Lisp, constants are not normally
copied by COMPILE, but since COMPILE does coalesce constants, it may
cause QUOTE to return an object which is not EQL to its original
argument.
There do not appear to be any implementations in which constants are
copied by EVAL.
Cost to implementors:
Proposal QUOTE-MAY-COPY:NOT-EVAL-OR-COMPILE would cause significant
problems for some implementations. For example, PSL/PCLS would
require major changes to its memory management scheme and garbage
collector as well as the compiler to bring it into compliance.
Proposal QUOTE-MAY-COPY:NOT-EVAL could potentially cause problems for
compiled-only implementations in which the in-memory compiler normally
coalesces or makes copies of constants. There does not appear to be
any existing implementation that would be affected.
Note that neither QUOTE-MAY-COPY:ALWAYS or QUOTE-MAY-COPY:NOT-EVAL
-require- constants to be copied or coalesced; neither proposal would
require changes to those implementations that currently don't touch
constants.
Cost to users:
Proposals QUOTE-MAY-COPY:ALWAYS and QUOTE-MAY-COPY:NOT-EVAL would have
the result of explicitly stating that programs which depend on COMPILE
preserving EQLness of constants are nonportable. (This is the de
facto situation now.) Such programs could continue to work in those
implementations in which COMPILE does not copy or coalesce constants.
The impact of allowing constants to be copied in interpreted code
(proposal QUOTE-MAY-COPY:ALWAYS) is unknown. It could be argued that
any code that depends on constants not being copied or coalesced is
broken, since it would not work when compiled in some implementations.
Benefits:
The semantics of QUOTE are clarified.
Discussion:
There has been some confusion about the names of the proposals. It's
been suggested that all of the proposals should be rewritten and
renamed to make it more clear that the issue is whether COMPILE or
EVAL may make copies of constants. Note that proposal
QUOTE-MAY-COPY:ALWAYS implies that copying is always *permitted*, but
is not required under any circumstances.
This issue has caused a very lengthy debate on the cl-compiler mailing
list, with no consensus arising yet. Following are comments
summarizing various people's positions.
Kent Pitman originally supported NOT-EVAL-OR-COMPILE, but now says:
I asked Moon about his feelings on this. He thinks pretty strongly that
the ALWAYS option is the only practical one to pursue. Partly, he says,
because it's maximally compatible with current practice and partly
because it avoids making COMPILE-FILE seem different.
In principle, I favor option ALWAYS, permitting copying of quoted
structure to a constants area in any of EVAL, COMPILE, or COMPILE-FILE
situations, as appropriate to the implementation.
It should not be concluded from this that I favor restrictions on the
kinds of data which may be quoted, however. The wording of option ALWAYS
should be ammended to say that such copying is permitted only when the
system can reliably deduce whether such copying is `appropriate,'
and avoid it in cases where it is not. The purpose of such wording would
be to avoid placing restrictions on what kinds of structures a user can
or cannot quote.
So, for example, if an implementor cannot in some context figure out how
to detect circularities in quoted structure in order to either decline
copying or correctly copy the circular form, then the implementation is
not permitted to attempt copying in such contexts.
Note however that because of special considerations forced by the external
representation of data in compiled files, I go along with (and encourage)
the establishment of a known subset of types which can be quoted (or used
as self-evaluating constants) in code to be reliably processed by the file
compiler. Coincidentally, such restrictions might make it easier for an
implementation to know whether copying was going to succeed in the case of
loading compiled code from a file, but technically these restrictions are
not motivated by any consideration of what kinds of structures might or
might not be possible to QUOTE.
My inclination is also to believe that copying should not be done
repeatedly, and we should find a way to express this. That is, repeated
execution of code in the same execution environment should return an EQL
result (or some such). This is important to guaranteeing efficiency. Even
in copying implementations, it is not necessary that such constants be
allocated in a read-only area or some such to achieve this effect. For
example, quoted structure could be placed in a special array and QUOTE
could be implemented using AREF. What is important is that any of these
permissions we give for copying not be taken for a license that QUOTE
should be implemented by COPY-TREE or some other operation which cannot
be done in constant time.
Dan Pierson says:
I also support QUOTE-MAY-COPY:NOT-EVAL-OR-COMPILE. In the absence of
overwhelming opposing reasons, we should not diminish traditional Lisp
functionality. While NOT-EVAL may be more in line with current
practice of a couple of implementations, the argument that these
implementations are already broken is at least as strong as the
argument that we shouldn't break them by pointing out that they don't
conform to the language standard.
However, my position on this is not unalterable.
Sandra Loosemore says:
I oppose NOT-EVAL-OR-COMPILE on the grounds that it differs from current
practice and would involve a substantial conversion cost for some
implementations; either of the other two alternatives would be acceptable
instead since they involve essentially no conversion cost for either
implementors or users. I am not convinced that the modifications to
proposal ALWAYS suggested by Pitman wouldn't cause just as much work
for some implementations as forbidding copying entirely. If the
modifications applied only to the behavior of EVAL and not COMPILE, that
would be OK.
Many people have referred to "tradition" in their arguments on this
issue. Different implementations have different traditions, and what
seems "broken" to one person may seem perfectly natural to another
person who comes from a different background.
JonL White says:
I favor giving as much leeway as possible to
the implementors for making memory-management optimizations. While one
implementor may choose not to do any such work, and another may even go
out of his way to assure EQLness over an unlikely set of circumstances,
this should not constrain the third from doing the "classic" thing. In
short, I don't see the value of adding constraints that
(1) invalidate much existing practice, and
(2) appear to be purely of theortical value.
Making "compiled code" (read: compile-file) work as closely as possible to
interpreted code is _not_ "purely of theortical value."
QUOTE-MAY-COPY:ALWAYS is the only proposal that both recognizes the
prevalent practice and pays (at least) lip service to the question of
compiled/interpreted consistency.
Cris Perdue says:
I am opposed to all of the proposals offered in their current
form.
CLtL takes a simple, useful approach to this problem. The idea
that QUOTE cannot reasonably operate as defined in CLtL is incorrect,
though it appears desirable to explain somewhere the "copying"
effects that compile-file may have on constants.
To say that QUOTE copies in existing implementations is to
imply that a lot of copying might happen that never actually
happens. COMPILE-FILE followed by LOAD effectively copies,
and in KCL, COMPILE effectively makes a copy, but not QUOTE.
I object strongly to suggestions that QUOTE copies in existing
practice, at least existing practice as I know it. Among other things,
this skews the entire discussion. It also limits the set of datatypes
that can be QUOTEd, because the equivalence defined in
CONSTANT-COMPILABLE-TYPES does not support all datatypes.
It is possible for QUOTE or a garbage collector to copy
constants into readonly storage, but I think that rationale is
different from supporting existing practice. With that rationale
I might support something like QUOTE-MAY-COPY:ALWAYS, but I think
it would be questionable whether the equivalence defined in
CONSTANT-COMPILABLE-TYPES is sufficient. A version
that applies to all objects might be advisable as the equivalence
maintained by QUOTE.
∂07-Jan-89 1048 X3J13-mailer **DRAFT** issue CONSTANT-COMPILABLE-TYPES
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:48:44 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20422; Sat, 7 Jan 89 11:47:34 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08919; Sat, 7 Jan 89 11:47:31 MST
Date: Sat, 7 Jan 89 11:47:31 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071847.AA08919@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue CONSTANT-COMPILABLE-TYPES
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: CONSTANT-COMPILABLE-TYPES
References: CLtL pp. 56, 77-80, 324
Issue CONSTANT-MODIFICATION
Issue CONSTANT-CIRCULAR-COMPILATION
Issue CONSTANT-ARRAY-ATTRIBUTES
Issue QUOTE-MAY-COPY
Issue LOAD-OBJECTS
Category: CLARIFICATION, ADDITION
Edit history: 11/07/88, V1 by Cris Perdue
11/14/88, V2 by Cris Perdue
11/22/88, V3 by Cris Perdue
12/20/88, V4 by Cris Perdue
01/06/89, V5 by Sandra Loosemore (minor editorial
clarifications, expand discussion)
Status: **DRAFT**
Problem description:
CLtL does not specify what objects can be in compiled constants and it
does not say what relationship there can or must be between the
constant passed to the compiler and the one that is established by
compiling and then loading its file. Relevant remarks in CLtL
concerning file compilation and the definition of QUOTE suggest that
the compiler handles constants in ways that are not actually possible.
Introduction to the proposal:
The proposal CONSTANT-COMPILABLE-TYPES:SPECIFY attempts to spell out
what types can appear in compiled constants, and what it means when
they appear. Unless stated otherwise, in this proposal where the term
"constant" is used, it means a quoted or self-evaluating constant, not
a named (defconstant) constant.
The key is a definition of a form of equivalence between Lisp objects,
"similarity as constants". Code passed through the file compiler must
behave as though quoted constants in it are equivalent to quoted
constants in the corresponding interpreted "source" code. This
proposal only concerns quoted constants to be processed by
COMPILE-FILE.
For the benefit of users, this proposal tries to define a fairly large
set of types that all Common Lisp implementations are to handle. It
also attempts to leave room for implementations to differ. Some
implementations have made opposing choices because the language
doesn't specify one over the other. Some implementations already
handle constants that this proposal defines as not legal in Common
Lisp programs, and that is useful to users of those systems.
Different implementors have different amounts of resources to apply to
their system, and implementations differ in their whole approach in
some cases.
We try to set up a framework where some controversies can be defined
clearly and resolved as separate issues.
One of these is the question of when, if ever, to permit "coalescing"
of constants. Some implementations already take advantage of the
license given on page 78 of CLtL to gain some efficiencies. This
proposal provides definitions that make it possible to broaden the
conditions where coalescing is permitted (see related issue
CONSTANT-COLLAPSING).
Another question is whether "circular" constants are compilable (issue
CONSTANT-CIRCULAR-COMPILATION). Most implementations are capable of
supporting circular constants. Still, this proposal avoids requiring
all implementations to handle circular constants. Implementations
that do not handle circular constants presumably also do not make sure
that shared structure remains shared, sort of the opposite of
coalescing. This proposal avoids requiring shared structure to remain
shared across compilation.
Some implementations "lose information" about some constants during
compilation. We try to limit this proposal enough to reduce the
number of unhappy implementors to a bare minimum.
In this version, the question of immutability of some attributes of
objects in compiled constants is not addressed. Cris has taken that
material out of this proposal and is constructing a new proposal
covering just that issue. This proposal does define the concept of
"basic attributes" of various types of objects, and the other proposal
will refer to it, stating that most basic attributes of most types of
objects may be treated as immutable when the object appears in a
compiled constant.
Proposal: CONSTANT-COMPILABLE-TYPES:SPECIFY
An object may be used as a quoted constant processed by COMPILE-FILE
if the compiler can guarantee that the resulting constant established
by loading the compiled file is "similar as a constant" to the
original, plus a few other restrictions.
A few types, such as streams, are not supported in constants. In
other words, an object containing one of these is not considered
similar as a constant to any other object. We say that it is an error
for these objects to appear in a (compiled) constant. Still some
implementations may support them and define how they are treated.
Some types of objects are treated as aggregate objects. For these
types, being similar as constants is defined recursively. We say that
an object of these types has certain attributes, and to be similar as
a constant to another object, the values of the corresponding
attributes of the two objects must also be similar as constants.
This kind of definition has problems with circular or "infinitely
recursive" objects such as a list that is an element of itself. We
consider the idea of depth-limited comparison, and say that two
objects are similar as constants if they are similar at all finite
levels. This idea is implicit in the definitions below, and applies
in all the places where attributes of two objects are required to be
similar as constants.
The rest of this proposal consists of a definition of the notion of
two objects being "similar as constants", organized by type, with some
notes about the additional constraints that the compiler must meet:
Number, Character
If either of two objects is a number or character, the two objects
are similar as constants if and only if they are EQL.
(Note that for cross-compilers it is not always possible to satisfy
this requirement for floating point numbers and complex numbers with
floating point parts. If it is necessary to choose two different
floating point values due to cross-compilation, each value chosen must
be one of the two adjacent, exactly representable numbers such that
the interval between them contains the other number. Other numbers
and characters are represented exactly, so they can be compared if
they are representable on both architecture, an issue for some
characters.)
Random-state
Only the operations PRINT, MAKE-RANDOM, and RANDOM apply to
random-states. Let us say that two random-states are functionally
equivalent if applying RANDOM to them repeatedly always produces the
same pseudo-random numbers in the same order.
Two random-states are similar as constants exactly if copies of them
made via MAKE-RANDOM-STATE are functionally equivalent.
Symbol
A symbol can only be similar to a symbol. References to symbols are
permitted in any constant. References to interned symbols are "by
name". If the symbol is interned, its name and the name of its home
package identify it.
A symbol with a home package is similar as a constant to a symbol when
the names of the symbols and the names of the home packages of the
symbols are similar as constants. (Both symbols must have home
packages.) Within a Common Lisp "address space", this implies that
the symbols are EQ.
If a symbol is not interned, i.e. its home package is NIL, it is
treated in a rather special way. To be similar as a constant to
another symbol, both symbols must be uninterned and have the same
name.
Constants that contain uninterned symbols have to satisfy an extra
constraint. The compiler must arrange that, within a file being
compiled with COMPILE-FILE, references to uninterned symbols that
are EQ in the source code must remain EQ in the compiled code.
Likewise, uninterned symbols that are not EQ must remain non-EQ after
compilation.
Package
A package can only be similar as a constant to a package. References
to packages are permitted in any constant. References to packages are
"by name": two packages are similar as constants when their names are
similar as constants. Within a Lisp "address space", packages with
the same name are EQ.
At load time, the package becomes the same as returned by
FIND-PACKAGE, given the package name. An error is signalled if no
package of that name exists at load time.
OTHER TYPES
-----------
For each of the types listed below, if either object is of the given
type, the two objects are similar as constants exactly if the other is
of that type and the values of all of the specified attributes are
similar as constants.
The attributes listed here can be called the "Basic Attributes" of
objects of each of these types.
Cons CAR, CDR.
Array For 1-dimensional arrays:
LENGTH and ELT for all legal indices.
For arrays of other dimensions:
ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all legal
indices.
Note that array constants in a compiled file may lack
displacement, fill pointers, or adjustability, where the
constants in the source had them, but the compiler may
not produce constant arrays that have these features from
ones that do not. The point is to make sure that
declarations are not violated as a result of compilation.
Structure Slot values, name of structure type (a symbol reference).
Hash-table Keys and values. The table's test is of course unchanged
also. It is an error to compile a constant containing a
a hash table that has keys that are similar as
constants.
Readtable Character syntax type for each character in the table;
function for each readmacro character, mappings for
dispatch macros; whether terminating or nonterminating
for each readmacro.
Pathname Each pathname component
Stream, Compiled-Function
It is an error for a stream or compiled-function
to appear in a compiled constant, but the
language may be extended in the future to support certain
cases.
Function Function constants that are not compiled-functions and do
not close over any (lexical) variables are permitted in
compiled constants. Two functions are similar as
constants when they are operationally equivalent. Use of
global function bindings, global macro bindings, and
special variables must be considered external
dependencies for this purpose, and constants appearing in
the functions need only be similar as constants (at level
n-1?).
Generic-function, Method
Help is needed from the CLOS committee to determine what
to do here. (Presumably they would be treated in the same
way as ordinary functions?)
Standard-object
Help is needed from the CLOS committee to determine what
to do here. (There is a cl-cleanup issue, LOAD-OBJECTS,
pending which proposes a mechanism for dealing with
objects.)
Rationale:
This proposal appears to reflect user demand and appears not to exceed
the capabilities of most implementations of the language.
Current practice:
This is believed to be very close to compatible with the Franz, Lucid,
Coral, and Texas Instruments implementations. It is probably
compatible or nearly compatible with other "Lisp Machine"
implementations.
Adoption cost:
Not known. Probably moderate or low -- for most implementations. The
cost would be to implementors rather than users since this part of the
language is currently underspecified. The author believes the cost
will be reasonable for KCL, an implementation where there is some
concern about this issue.
Benefits:
Users would be able to use aggregate objects in constants with
confidence about the behavior of their code.
Conversion cost:
Where this proposal *requires* different behavior than an existing
implementation, there is a conversion cost for users of that
implementation. It appears that this cost will be small, less than
the cost of leaving things unspecified.
Esthetics:
Since there is no adequate definition at present, a fuller definition
would be more esthetic.
Discussion:
This proposal does leave some user-visible attributes of objects
unspecified across the compile-and-load process, except that they must
be consistent with the attributes that must be retained. This
situation is a compromise between the desire for full specification on
the one hand, and on the other hand the desire to leave freedom for
different implementations to remain different and to support some
optimizations such as compacting hash tables and "simplifying" arrays.
Proposals will be entertained for tighter specification of datatypes
such as arrays.
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
Comparing functions is hard. One could define an operation that
converts an interpreted function into a lambda expression. One could
say that interpreted functions are similar as constants when their
associated lambda expressions are similar in the appropriate sense.
This similarity of lambda expressions would be syntactic, but would
have to allow for possible inline macro expansion. Other
transformations would have to be prohibited, or the functions would
have to report themselves as compiled.
This proposal seems to deal with the question of how to test whether
constants in different Lisp address spaces are similar as constants.
That appears to be important.
We need someone expert with floating-point computation to review the
discussion of similarity of floating point numbers as constants.
The definition of similarity for random-states supports the
possibility of random states that are immutable because of being in
compiled constants.
Interest has been expressed by a number of people including users, in
support for user-definable "dumping" of CLOS objects and structure
instances. The cleanup issue LOAD-OBJECTS deals with this.
This subsumes the issue CONSTANT-ARRAY-ATTRIBUTES.
Most of the recent discussion on this proposal has centered around the
handling of functions and readtables, and on aspects relating to CLOS.
Sandra Loosemore notes:
Dumping a constant readtable is not likely to be particularly useful
in an implementation that cannot dump compiled function constants.
(In particular, readtables derived from the standard Common Lisp
readtable are likely to "contain" mostly compiled functions.) I'm
also not convinced that requiring non-compiled, non-closed function
constants buys anything for the user, since an implementation is
always free to make all functions compiled. It seems like it would be
simpler just not to require any function constants to be dumpable.
Jeff Dalton responds:
Although I didn't say anything about it before, I was always bothered
by the idea that functions would be dumped in readtables. Since it's
pretty clear that not all implementations can dump all functions, users
can't rely on it at all; and then the whole idea of dumping a readtable
begins to seem suspect.
JonL White notes:
The analogy between FIND-PACKAGE and FIND-CLASS suggests that class
objects are in the same "database" category as packages. Shouldn't
they be referenced "by name" in compiled file?
Moon responds:
In Flavors we generate metaobjects at compile time, but we never put
them (to speak loosely) into the compiled-code file; instead macros
like DEFFLAVOR and DEFMETHOD expand into Lisp code that obtains new
metaobjects at load time, based on the class name and generic function
name. I don't see how any other way could work, actually, since two
distinct compiled files that refer to a class by the same name must
end up referring to the same metaobject after loading. In Flavors we
don't have anonymous classes nor anonymous generic functions, so we
don't have to solve those issues.
[Issue LOAD-OBJECTS proposes] that the way to load an instance of a
standard-class from a compiled file is for a method of the instance
to return a form which is then evaluated at load time. The semantics
of loading an instance of a standard-class from a compiled file can be
entirely understood in terms of MAKE-INSTANCE or whatever other
function is called by the form returned by MAKE-LOAD-FORM; no new
concepts need be introduced. If the programmer of a given class wants
to use the class redefinition protocol, that class's MAKE-LOAD-FORM
method can output something that uses that protocol, and if he
doesn't, it can output something that doesn't.
∂07-Jan-89 1316 X3J13-mailer **DRAFT** issue DEFINING-MACROS-NON-TOP-LEVEL, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 13:12:18 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA23191; Sat, 7 Jan 89 14:11:10 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08985; Sat, 7 Jan 89 14:11:06 MST
Date: Sat, 7 Jan 89 14:11:06 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901072111.AA08985@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue DEFINING-MACROS-NON-TOP-LEVEL, version 7
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: DEFINING-MACROS-NON-TOP-LEVEL
References: CLtL p. 66-70, 143
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue COMPILER-LET-CONFUSION
Category: CLARIFICATION, ENHANCEMENT
Edit History: 6-May-88, V1 by Sandra Loosemore
9-Jun-88, V2 by Sandra Loosemore
12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)
21-Sep-88, V4 by Sandra Loosemore (clarify section 5)
16-Dec-88, V5 by Sandra Loosemore (major restructuring)
31-Dec-88, V6 by Sandra Loosemore (wording clarifications)
07-Jan-89, V7 by Sandra Loosemore (add example)
Status: **DRAFT**
Problem Description:
CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unclear.
On page 66, it is stated: "It is not illegal to use these forms at
other than top level, but whether it is meaningful to do so depends on
context. Compilers, for example, may not recognize these forms
properly in other than top-level contexts". At least one implementation
has interpreted this to mean that it is permissible to simply refuse
to compile defining macros that do not appear at top-level.
Proposal: DEFINING-MACROS-NON-TOP-LEVEL:ALLOW
(1) Remove the language from p. 66 of CLtL quoted above. Clarify that
while defining macros normally appear at top level, it is meaningful
to place them in non-top-level contexts and that the compiler must
handle them properly in all situations. However, the compile-time side
effects described in issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
only take place when the defining macros appear at top-level.
(2) Remove the language on p. 145 of CLtL, which states that macro
functions are always defined in the null lexical environment. Clarify
that all defining macros which create functional objects (including
DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
DEFSETF, as well as DEFUN) must ensure that those functions are
defined in the lexical environment in which the defining form is
evaluated.
(3) Define a ``top-level form'' as follows:
- Each form read by COMPILE-FILE from the input file is a top-level
form.
- Forms within the body of a top-level PROGN, EVAL-WHEN, or
COMPILER-LET are also top-level forms.
- The expansion of a top-level macro call is also a top-level form.
Top-level forms would be evaluated by the interpreter in a null
lexical environment, but evaluation in a null lexical environment does
not necessarily imply that the form is top-level.
(4) Specify that top-level forms in a file being compiled are
guaranteed to be processed sequentially, including forms within the
body of a top-level PROGN, EVAL-WHEN, or COMPILER-LET. The order in
which non-top-level subforms of a top-level form are processed by the
compiler is explicitly left unspecified.
Rationale:
The notion of a ``top-level form'' is rather confused, since the term
is used in CLtL to refer both to a place where a form may appear (what
this proposal continues to call ``top-level''), and to instances of
forms which traditionally appear there (what this proposal calls
``defining macros'').
There has been a suggestion that the notion of a top-level form should
be extended to include forms in the body of a top-level LET, to allow
forms such as DEFUN to be meaningful there. However, we feel that a
cleaner solution is to remove the restrictions on the placement of
defining macros altogether.
Item (4) serves two purposes. First, it guarantees users that
compile-time side-effects from top-level EVAL-WHEN forms or defining
macros will happen in the correct order. Second, it allows compilers
to perform certain kinds of source-to-source transformations that
change the order of subforms.
For instance, the following example from CLtL
(let ((old-count *access-count*))
(unwind-protect
(progn
(incf *access-count*)
(perform-access))
(setq *access-count* old-count)))
is entirely equivalent to:
(let ((old-count *access-count*))
(let ((thunk #'(lambda () (setq *access-count* old-count))))
(unwind-protect
(progn
(incf *access-count*)
(perform-access))
(funcall thunk))))
(This is a real example from the A-Lisp compiler, which implements
UNWIND-PROTECT by having it push a "thunk" to perform the cleanup
actions onto the catch stack before executing the protected form.)
Current Practice:
CLtL mentions only that forms within a top-level PROGN, and not
COMPILER-LET, are treated as top-level. However, COMPILER-LET is
also treated specially in implementations derived from the MIT Lisp
Machine (TI and Symbolics), as well as Lucid and Coral (but not
VaxLisp).
Cost to implementors:
Implementations that currently don't compile defining macros correctly
when they appear at non-top-level will have to be changed.
Cost to users:
None. This is a compatible extension.
Benefits:
The notion of defining macros as being somehow special when they
appear at top-level is removed. Allowing defining macros to appear
anywhere instead of restricting them to certain positions results in a
cleaner language design.
Discussion:
This proposal is consistent with the behavior specified in proposal
EVAL-WHEN-NON-TOP-LEVEL:IGNORE-COMPILE. In particular, if the compile
time side-effects for defining macros specified in proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY are implemented using
EVAL-WHEN, the "right" compiler behavior for defining macros at
non-top-level will happen automatically.
The issue of whether the bodies of top-level EVAL-WHENs should also be
considered top-level is controversial, as it effects the nesting
behavior of EVAL-WHEN. See issue EVAL-WHEN-NON-TOP-LEVEL for details.
There has also been a suggestion that MACROLET bodies should be
considered top-level. IIM Common Lisp implements this.
Note that proposal COMPILER-LET-CONFUSION:ELIMINATE would remove
COMPILER-LET from the language entirely.
∂07-Jan-89 1311 X3J13-mailer **DRAFT** issue EVAL-WHEN-NON-TOP-LEVEL, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 13:11:33 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA23183; Sat, 7 Jan 89 14:10:25 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08982; Sat, 7 Jan 89 14:10:22 MST
Date: Sat, 7 Jan 89 14:10:22 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901072110.AA08982@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue EVAL-WHEN-NON-TOP-LEVEL, version 4
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: EVAL-WHEN-NON-TOP-LEVEL
References: CLtL p. 69-70
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CHANGE, CLARIFICATION
Edit History: 6-May-88, V1 by Sandra Loosemore
16 Dec 1988, V2 by Sandra Loosemore (alternate direction)
30 Dec 1988, V3 by Sandra Loosemore (minor wording changes)
07 Jan 1989, V4 by Sandra Loosemore (update discussion)
Status: **DRAFT**
Problem Description:
The current description of how the compiler should handle EVAL-WHEN
only makes sense when it appears as a top-level form in the file being
compiled. Is it legitimate for EVAL-WHEN to appear in non-top-level
locations? What does it mean in such places?
Proposal EVAL-WHEN-NON-TOP-LEVEL:IGNORE-COMPILE:
Clarify that EVAL-WHEN may appear both at top-level and at
non-top-level. In non-top-level locations, however, the COMPILE
situation is effectively ignored.
More specifically, when an EVAL-WHEN form is processed by the
interpreter (that is, by the function EVAL), the presence of the EVAL
situation indicates that the body of the EVAL-WHEN should be evaluated
as an implicit PROGN. Otherwise, EVAL-WHEN returns NIL without
evaluating the body. The interpreter ignores the COMPILE and LOAD
situations.
When an EVAL-WHEN form is processed by the compiler:
First, if the situation COMPILE is specified:
- If the EVAL-WHEN form appears at top level (as defined in
proposal DEFINING-MACROS-NON-TOP-LEVEL:ALLOW), then each of
the forms within the body of the EVAL-WHEN are evaluated by
the compiler in the null lexical environment using the
function EVAL.
- Otherwise, no compile-time evaluation takes place. An
implementation is permitted to signal a warning to indicate
that the compile-time evaluation is being ignored.
Then, if the situation LOAD is specified, then the compiler treats
the body of the EVAL-WHEN form as if it were an implicit PROGN.
If the situation LOAD is not specified, then the compiler should
treat the EVAL-WHEN form as if it were a constant value of NIL.
The compiler ignores the EVAL situation.
Rationale:
Restricting compile-time evaluation to top-level locations prevents
complications resulting from performing the evaluation in the wrong
lexical environment.
This definition of how EVAL-WHEN behaves is much simpler than that
given in CLtL, and makes it easier to explain its nesting behavior.
Allowing implementations to signal a warning when ignoring a
non-top-level EVAL-WHEN allows users to be informed that something
unusual is going on.
Current Practice:
IIM Common Lisp implements this proposal. Kim Barrett contributed the
following code that illustrates their implementation:
(defmacro eval-when (situations &body body &environment env)
(if (not (compiler-environment-p env))
(when (member 'eval situations) `(progn ,@body))
(progn
(when (member 'compile situations)
(if (compiler-at-top-level-p env)
(mapc #'eval body)
(warn "Top-level form encountered at non-top-level.")))
(when (member 'load situations) `(progn ,@body)))))
Cost to implementors:
Probably fairly minor in most implementations.
Cost to users:
Except for the change relating to possible multiple evaluation of
nested EVAL-WHENs, this proposal is a compatible extension.
Benefits:
The behavior of EVAL-WHEN is easier to understand. Making EVAL-WHEN
meaningful at non-top-level locations makes it more generally useful,
for example in the expansion of defining macros.
Discussion:
The behavior specified for top-level EVAL-WHENs in this proposal
differs slightly from that described in CLtL. In the case where both
COMPILE and LOAD are specified, CLtL indicates that the compile-time
evaluation should be interleaved with normal compiler processing of
each of the forms in the body, while this proposal specifies that the
evaluation of all of the body forms should take place before any of
the normal compiler processing. However, it is unlikely that this
would cause serious problems for any user programs.
The nesting behavior of EVAL-WHEN as described in CLtL has been
criticized as overly complicated and hard to understand, while this
proposal is much less complicated. However, the behavior of nested
EVAL-WHENs in this proposal is strongly tied to the definition of the
term "top-level"; see proposal DEFINING-MACROS-NON-TOP-LEVEL:ALLOW.
If the bodies of top-level EVAL-WHENs are also considered to be
top-level, this leaves open the possibility that nested EVAL-WHENs may
cause multiple compile-time evaluations. For example,
(eval-when (eval compile load)
(eval-when (eval compile load)
(punch-paper-tape)))
would cause PUNCH-PAPER-TAPE to be called twice at compile time (once when
the outer EVAL-WHEN is processed, and again when the inner EVAL-WHEN is
processed). Some people think this behavior would be unacceptable.
This problem could be "fixed" by not considering the bodies of top-level
EVAL-WHENs to be top-level forms. In this case, outer EVAL-WHENs would
always override any nested EVAL-WHENs. For example,
(eval-when (eval load)
(eval-when (eval compile load)
(punch-paper-tape)))
would not cause *any* compile-time call to PUNCH-PAPER-TAPE. This
represents an incompatible change from the behavior of EVAL-WHEN
described in CLtL, where wrapping a form with (EVAL-WHEN (EVAL LOAD)
...) is essentially a no-op. Some people think the change would be a
good idea, others are uncertain whether the resulting cleaner
semantics would justify it.
As a compromise position, we could say that EVAL-WHEN passes
top-level-ness on to its body only if the COMPILE situation is not
specified.
Some people are not comfortable with messing with the definition of
top-level at all. On the other hand, others think it is important
that EVAL-WHEN and the various defining macros should apply consistent
rules for deciding when it is appropriate to perform compile-time
magic.
A final alternative is to go back to describing EVAL-WHEN the way it
was in CLtL, with a compile-time-too state variable.
∂08-Jan-89 2342 CL-Compiler-mailer **DRAFT** issue CONSTANT-COMPILABLE-TYPES
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 23:41:53 PST
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Mon, 9 Jan 89 02:35:59 EST
Received: by kulla.think.com; Mon, 9 Jan 89 02:38:15 EST
Date: Mon, 9 Jan 89 02:38:15 EST
From: barmar@Think.COM
Message-Id: <8901090738.AA09372@kulla.think.com>
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 7 Jan 89 11:47:31 MST <8901071847.AA08919@defun.utah.edu>
Subject: **DRAFT** issue CONSTANT-COMPILABLE-TYPES
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
I guess my last message can be thought of as endorsing this idea.
barmar
∂09-Jan-89 0848 X3J13-mailer Editorial committee issues
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:48:01 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15007; Mon, 9 Jan 89 08:46:48 PST
Message-Id: <8901091646.AA15007@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:44
To: x3j13@sail.stanford.edu
Subject: Editorial committee issues
The editorial committee has completed discussion of 5 issues and
would like to bring them to vote, if possible, in Hawaii. Although
there will be copies available in Hawaii, please review these issues
and send comments to cl-editorial.
Thanks for your time.
kathy chapman
∂09-Jan-89 0849 X3J13-mailer Issue:DEPRECATION-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:49:26 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15093; Mon, 9 Jan 89 08:48:13 PST
Message-Id: <8901091648.AA15093@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:47
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:DEPRECATION-POSITION
Issue: DEPRECATION-POSITION
References: X3J13 committee and sub-committee meetings
Category: Policy
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
Problem Description:
When features of a language become outdated due to technology advances,
or unnecessary due to the addition of better features, should the old
features be deprecated from the language, or deleted outright?
Since there has never been a Common Lisp standard before, deprecation
is against a de-facto standard, which may or may not be appropriate.
Deletion, on the other hand, is cleaner, but may generate never-ending
discussion when the standard goes for public review (and even in the
X3J13 meeting).
In summary, there are two levels:
1) features in CLtL that are not present in ANSI Common Lisp 1989,
2) features in ANSI Common Lisp 1989 that will likely not be present in
future standards;
and the issues are:
a) what features fit into which category
b) how should implementations deal with such features? how can programs be
written to avoid problems with such features?
Proposal (DEPRECATION-POSITION:LIMITED)
Since Common Lisp has been used industrially, it is reasonable to
assume that any level 1 feature will be a cause for
at least some controversy. Therefore, this proposal suggests that
X3J13 put features categorized as level 1 in a separate package,
and retain features categorized as level 2 in the Lisp package, but
declare them deprecated in the standard.
The members of each level will be determined on a case-by-case basis by
the X3J13 committee.
Rationale:
The standard should contain information about deprecation since
the topic has been mentioned more than once in X3J13, and since
Common Lisp is such a large language.
It's not
unreasonable for a language the size of Lisp to get rid of the
never-used tools, but we don't want to generate years of discussion
over a relatively minor issue when the standard goes for public review.
Current Practice:
Fortran successfully deprecated one constant. However, a proposal
submitted during its latest standardization effort that
suggested deleting old features in favor of new ones was
opposed vehemently. The Pascal committee is currently opposed
to deprecation, and the SPARC proposal suggests that
deprecation should be dictated by the marketplace.
Adoption Cost:
None.
Benefits:
This policy will provide a basis for future X3J13 decisions.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comment:
"I personally would argue for not including "deprecated" features in
the standard at all, because including them now will make it harder to
remove them later. My perception is that ANSI Common Lisp is turning
out to be a much different language than what is described in CLtL,
particularly if CLOS becomes a required part of the language. If,
with the benefit of hindsight and experience, we now realize that some
"features" described in CLtL were really "bugs", the time to remove
them is *before* they become cast in stone as part of ANSI Common
Lisp. I suspect that most implementors will continue to provide these
features as extensions anyway, as long as a substantial number of
their customers are still using them."
Response:
Perhaps most implementors will continue to provide the deleted features,
but they will do that also if they are deprecated. Since the only real
difference between the two is the amount of discussion one will generate
over the other (I think that worrying about future difficulty of getting
rid of the features is not a "real" difference yet), it seems that choosing
the route of least resistance in this case is the wisest course.
Comment:
"For the most part, X3J13 hasn't been able to deal with
which features fit into which category until how the categories will
be divided has been resolved. In particular, there are a number of
features that we didn't want to remove from ANSI Common Lisp 1989 if
it would be awkward for implementations to continue to support them or
programs to continue to use them, but wanted to at least declare them
"obsolete". There's been some debate on whether CHAR-FONT, for
example , should be deleted before the standard is written, or declared
deprecated within the standard."
∂09-Jan-89 0851 X3J13-mailer Issue:SUBSETTING-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:51:25 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15185; Mon, 9 Jan 89 08:50:10 PST
Message-Id: <8901091650.AA15185@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:49
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:SUBSETTING-POSITION
Issue: SUBSETTING-POSITION
References: X3J13 committee and sub-committee meetings
Category: Policy
Edit history: 12-DEC-88, Version 1 by Chapman
9-JAN-89, Version 2 by Chapman (with discussion by Masinter)
Problem Description:
Should the CL standard be partitioned such that an implementation
could chose a subset of all the CL facilities to implement and
still be a conforming implementation?
What subsets should be specified in the draft standard we submit to
ANSI?
What position should we take if someone should propose a subset?
Proposal (SUBSETTING-POSITION:NONE)
The draft standard we submit to ANSI
contains *no* subsets. In the section on "subsetting" it should be mentioned
that Lisp is a "small" language with a "big" library and that the conventional
mechanism for allowing small memory images is auto-load.
Rationale:
Current Practice:
Pascal has two levels of conforming implementations -- level 1 contains
level 0 and conformant arrays. This was a compromise necessary to achieve
international agreement. The 1981 PL/I was subsetted and the
results were a range of implementations between the
subset and the full language; nobody wanted to use the subset so vendors
were forced to implement the full language eventually anyway.
Cobol had multiple levels of subsets. However,
the only two levels that were important were the minimum
subset and the full language. The middle levels were
seldom used other than transient points to the full language.
Fortran was subsetted. It was felt that subsetting encouraged
vendors to implement Fortran and therefore proliferate its usage,
but users were quite annoyed that one Fortran was considerably
different from another.
The new Fortran language standards committee is
banning subsetting.
SPARC feels that
subsets aren't good for facilitating interchange, but serve the
purpose of allowing
timely implementation of the standard.
A suggestion that was made by most language committee representatives
was to group subsetted parts meaningfully, and to minimize the number
of levels.
Adoption Cost:
None.
Benefits:
This policy will provide a basis for making decisions in X3J13.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
First of all, we should review the possible kinds of subsets one might
have: subsets might omit syntax, functions, admissable values or arguments
to functions, or data types. For example, a subset might disallow SPECIAL
declarations (a syntactic subset), might omit the COS, SIN, ATAN functions,
might disallow the :TEST keyword to MAKE-HASH-TABLE, might restrict TAILP
to work on proper lists, or might omit complex numbers. Each of these is a
"subset" in the sense that a subset of correct programs for the "full"
language would be correct for the "subset" language.
Subsets can have various levels of "determinability" for programs. The
issue is: how easy is it to tell whether a program written in the "full"
language would run in a "subset" implementation? Except for the
(non-trivial) issue of macro expansions, some subsets are "lexically"
determinable, e.g., if a function is omitted, you can tell if the program
uses it by scanning the program. Some subsets are "dynamically"
determinable, e.g, a subset might signal an error if the :TEST argument to
MAKE-HASH-TABLE is EQUALP. Some subsets are neither lexically nor
dynamically determinable, e.g., if the subset implements dynamic extent for
rest lists, it may be impossible to tell even with run-type checks whether
the a program written in the "full" language would conform.
Some "subsets" might be merely restrictive interpretations, e.g., a
"run-time" implementation that made ED, TRACE, UNTRACE into no-ops and made
BREAK halt the program execution rather than "enter the debugger"; since we
cannot define what "enter the debugger" means, we might want to define
explicitly this subset as a reasonable one for embedded systems.
∂09-Jan-89 0851 X3J13-mailer Issue:CUT-OFF-DATES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:50:53 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15165; Mon, 9 Jan 89 08:49:39 PST
Message-Id: <8901091649.AA15165@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:49
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:CUT-OFF-DATES
Issue: CUT-OFF-DATES
References: Working draft of the standard
Category: Policy
Edit history: 20-DEC-88, Version 1 by Chapman
9-JAN-89, Version 2 by Chapman
Problem Description:
The X3J13 committee has informally agreed that a 12/89 standard is
a doable goal. However, the standard has to be reviewed by a large
number of people outside the X3J13 committee. We must allow plenty
of time for these reviews, and should therefore plan our internal
reviews and "document freeze" accordingly.
Proposal (CUT-OFF-DATES:ESTABLISH)
Item Cut-off date for changes
________________________________________________(First day of the month)____
Format of tool descriptions 11/88
Meaning of each item in each tool description 11/88
Fonts 2/89
Changes to existing functions 4/89
Additional functions 4/89
Compliance 2/89
Error terms 2/89
Contents of Chapter 6 tool descriptions:
- Syntax section 2/89
- Arguments section 5/89
- Values section 5/89
- Description section 5/89
- Examples section 2/89
- Side Effects section 3/89
- Affected By section 3/89
- Conditions section 4/89
- See Also section 2/89
- Notes section 5/89
Changes to TOC 2/89
Contents of sections: 4/89
- 1.1 4/89
- 1.2 4/89
- 1.3 4/89
- 1.4 4/89
- 1.5 4/89
- 1.6 4/89
- 1.7 4/89
- 1.8 4/89
- 2.1 5/89
- 2.2 5/89
- 2.3 5/89
- 2.4 5/89
- 2.5 5/89
- 3.1 5/89
- 3.2 5/89
- 4.1 6/89
- 4.2 6/89
- 5.1 6/89
- 5.2 6/89
- 5.3 6/89
- 5.4 6/89
The way this breaks down is as follows:
Things that have already frozen: format of Chapter 6 tool descriptions,
meaning of each tool description category.
Things that will be frozen after the 1/88 meeting: fonts, compliance,
error terms, syntax section, examples section, see also section,
side effects section, affected by section, table of contents, and
this schedule of cut-off dates.
Things that will be frozen after the 3/88 meeting:
Contents of Chapters 1, 2, and 3, New issues that change existing functions
or add new functions, values section, arguments section, description
section, notes section, and conditions section.
Things that will be frozen by 6/1/89:
Chapters 4 and 5.
All comments received according to this schedule will be incorporated
by 6/30/89. Any comments received after the dates listed above will
only be considered if they are of an extreme nature, if they impact
the correctness of the document. Otherwise the comments will be filed
and reserved for the next standard.
To change these dates, a 2/3 vote of the editorial committee
or a majority vote of X3J13 is required.
Rationale:
In order to complete this standard and move on to the next version,
we need to establish dates after which changes will not be allowed.
Current Practice:
None.
Adoption Cost:
None.
Benefits:
Establishing cut-off dates will encourage reviewers to complete
a thorough review in a timely manner.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comment:
"There are a couple of areas where I expect some further work that might
impact these dates:
a) pathname functions
I'm still hoping to get some cleanup of many of the pathname issues
b) errors signalled, by name
I'm still hoping that we can get at least a partial listing, for each
function, of the possible errors signalled, under what circumstances.
c) pending cleanups
There will probably be 10-15 cleanup issues dealing with ambiguities that
will drag out beyond 3/89. I hope not, but I'm trying to be realistic;
there are just too many "open" issues left."
∂09-Jan-89 0852 X3J13-mailer Issue:CONFORMANCE-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:52:34 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15368; Mon, 9 Jan 89 08:51:17 PST
Message-Id: <8901091651.AA15368@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:50
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:CONFORMANCE-POSITION
Issue: CONFORMANCE-POSITION
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Related Issues: EXTENSIONS-POSITION, LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
Problem Description:
Two ways of defining conformance are in terms of a conforming program
and in terms of a conforming implementation. How should our standard
define conformance?
Proposal (CONFORMANCE-POSITION:PROGRAM)
The standard presents the syntax and semantics to be implemented by
a conforming implementation.
A conforming program is one that can be executed by a conforming
implementation with no unhandled exceptions and no unspecified
and potentially harmful consequences.
The basic test for conformance will be that a program written to the letter
of the standard will run in all "conforming" implementations.
The basic rules are as follows:
. Conforming programs use the syntax described in the standard.
. Conforming programs are written using the functions, macros,
special forms, variables, constants described in the standard.
. Conforming implementations provide the functions, macros, special
forms, variables, constants, and arrange that they behave in ways
that conform to the descriptions of them in the standard.
Rationale:
The standard must contain information about conformance. Including
requirements which would be placed on implementations, however, leaves
the possiblity open that something would be overlooked, and so
implementations may well conform without processing correctly
conforming programs.
Current Practice:
CLtL generally describes things in terms of what a correct program can
expect.
dpANS C is also in terms of programs. They have further defined
both "conforming" and "strictly conforming" programs; the
difference has something to do with how the program deals with features
that the standard says are implementation-defined.
Pascal defines
conformance in terms of both, PL/I defines conformance in terms of
conforming programs only.
Fortran and Ada say that a conforming implementation correctly processes
conforming programs. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both programs and implementations.
Adoption Cost:
None.
Benefits:
This definition will give readers and validators a basis on which to read
the standard.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comment:
I think we might want to introduce the notion of a "portable" program, as
well as a "conformal" one.
A "portable Common Lisp program" is a conformal Common Lisp program that
"works the same" in all conformal implementations.
Response:
There should be no difference, then between a portable program and a
conforming program. Why introduce new terms?
∂09-Jan-89 1155 X3J13-mailer Issue:EXTENSIONS-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 11:55:13 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA15119; Mon, 9 Jan 89 08:48:49 PST
Message-Id: <8901091648.AA15119@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:48
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:EXTENSIONS-POSITION
Issue: EXTENSIONS-POSITION
References: Chapter 1, Working draft of standard
Category: Clarification
Related Issues: CONFORMANCE-POSITION, IF-BODY
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
Problem Description:
What is the definition of a language extension?
What effect does a language extension have on a conforming program?
What obligation does an implementation have to warn the user that an
extension is being used?
Is it OK to define Common Lisp functions with extra optional or
keyword parameters, with system dependent meanings? E.g. Lucid's
COMPILE-FILE has several keyword arguments not mentioned in CLtL.
Is it OK to return extra values from Common Lisp functions?
Is it OK to define the behavior of functions on datatypes not
explicitly permitted in CLtL? For example, suppose + is defined on
vectors to do component-wise addition on the elements? Arguments to +
"must" be numbers, meaning that it "is an error" to supply anything
other than numbers, meaning that anything can happen when you supply
arguments other than numbers.
Proposal (EXTENSIONS-POSITION:DOCUMENTATION)
The standard document should define a language extension to be
any implementation-supplied tool that isn't explicitly defined
in the standard. This includes facilities added to tools defined
in the standard.
The standard document should levy the following requirement on a
conforming implementation's documentation:
The documentation that accompanies a conforming implementation should clearly
state which parts of the implementation are extensions.
Extensions that are associated with symbols that are external in the LISP
package are reasonable. Extensions to existing functions
as far as additional optional or keyword arguments are disallowed,
except where explicitly allowed. Extensions to existing functions as far as
data types allowed, extra arguments, or extra return values are disallowed
except where explicitly allowed.
If the standard says that "the results are unspecified", and an
implementation specifies the results, this an extension in the
sense that if the correct behavior of a program depends on the results,
only implementations with the same extension will execute the program
correctly.
Rationale:
The standard should contain information about language extensions
since most implementations have extended the language.
Current Practice:
CLtL allows any extension, provided that it doesn't alter the behavior
of a program that only uses what is specified in CLtL. In particular,
any situation that "is an error" (either explicitly or implicitly) is a
potential area for extension.
Adoption Cost:
Vendors will have to improve their documentation
to list all their extensions. Vendors will have to go through their
implementation and determine what is or isn't an extension.
Benefits:
This definition will provide a basis for proper understanding of
the error terminology used in the standard. The implementation
documentation requirement will aid the user in producing portable code.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comments:
"The most commonly proposed solution to this kind of problem is to
require the implementation to have a way to disable its extensions, so
that a programmer can be told when he is using a feature that might
affect his program's portability. Whether this should be the default
mode is up for debate; I think most other standards that do this don't
require it to be the default."
Response:
Requiring an implementation to be able to disable extensions seems like
a more costly alternative than requiring an implementation to document
its extensions as extensions if it is to be conforming, since presumably
an implementation will document user-visible extension anyway.
Comment:
It seems to be a constraint on "documentation" rather than "implementation"
if you turn the accidental behavior of (CAR T) into a "feature" of your
implementation. We might want to disallow such an extension as "conforming
to the standard". An implementation which had such an extension might
conform, even if the extension did not conform.
Response:
There are currently statements in the conformance section of the standard
that state what you have demonstrated here. They will be left in that
section.
∂09-Jan-89 1242 X3J13-mailer Re: Issue:SUBSETTING-POSITION
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jan 89 12:41:24 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06734; 9 Jan 89 19:42 GMT
Date: Mon, 9 Jan 89 19:43:21 GMT
Message-Id: <11708.8901091943@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue:SUBSETTING-POSITION
To: chapman <@decwrl.dec.com:chapman@aitg.dec>, x3j13@sail.stanford.edu
In-Reply-To: chapman's message of 9 Jan 89 11:49
Subsetting has long been a somewhat controversial topic, but I think
it is fair to say that "no subsets" is the dominant position in X3J13.
It is possible that subsets might be helpful at the ISO level, but
so far the idea of a subset (without any other changes) has not attracted
too great a following.
> Proposal (SUBSETTING-POSITION:NONE)
>
> The draft standard we submit to ANSI contains *no* subsets. In the
> section on "subsetting" it should be mentioned that Lisp is a "small"
> language with a "big" library and that the conventional mechanism for
> allowing small memory images is auto-load.
I'd be happier if it were fairly easy for someone reading the standard
to determine which part was the "library" and which the core language.
For example, where do we find FUNCALL and APPLY?
The draft C standard has an explicit division. Section 3 is
"Language" and section 4 is "Library". It may not be necessary
to go that far for Common Lisp.
> Current Practice:
>
> The 1981 PL/I was subsetted and the results were a range of
> implementations between the subset and the full language; nobody wanted
> to use the subset so vendors were forced to implement the full language
> eventually anyway.
I'd be interested in knowing more of the PL/I story. As I recall, we
(Dartmouth) were quite happy with "Subset G".
I suppose you might want to add something about Basic. At one point,
there was an ANSI standard for "Minimal Basic". It was too minimal.
Later work on ANSI Basic involved a rather different-looking language
(think "structured control structures") and a number of optional
extensions for such things as real-time process control. I don't
know the details or what finally happened, but it looked fairly messy.
∂09-Jan-89 1303 X3J13-mailer revised ISO discussion, revised DRAFT Gegenda and Subcommittee meetings
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 13:03:27 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00910g; Mon, 9 Jan 89 12:59:24 PST
Received: by challenger id AA16753g; Mon, 9 Jan 89 12:55:22 PST
Date: Mon, 9 Jan 89 12:55:22 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901092055.AA16753@challenger>
To: x3j13@sail.stanford.edu
Subject: revised ISO discussion, revised DRAFT Gegenda and Subcommittee meetings
Guest Room 120 of the hotel has been reserved for Subcommittee meetings.
Please let me know how much time you need and what day and time you'll need.
I'll make up a scudule and post it.
---jan---
Monday, January 16
7:30am - ISO discussion, Chart room
We've found copying facilities to be very expensive at hotels. We intend not
to use their facilities. Please mail copies of reports to Liz Anne's
attention at the hotel if you intend to distribute reports to the meeting.
Participants are encouraged to bring copies of reports mailed to them to the
meeting.
X3J13 Committee Meeting Agenda DRAFT
January 16 - 18, 1988
1 Call to Order, January 16, 9:00am Chart Room
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Character Subcommittee Report, Thom Linden (2 hours)
7 Coffee Break 10:30
8 Character continuation
9 Chapter 3 CLOS, Gregor Kiczales (1 hour)
10 LUNCH 12:00 Voyage Room Restaurant
11 Compiler Subcommittee, Sandra Loosemore (2 hours)
12 Iteration Subcommittee Report, Jonl White (30 minutes) 89-004
13 Recess 3:00
14 Call to Order, 8:00pm
15 Editorial Subcommittee Report, Kathy Chapman (1 hour)
16 Other Subcommittee Reports
16a Recess 10:00
17 Call to Order, January 17, 9:00am Chart Room
18 Other Subcommittee Reports
19 Coffee Break 10:30am
20 Cleanup Subcommittee, Larry Masinter
21 Lunch 12:00 Voyage Room Restaurant
22 Cleanup continuation
23 Break 3:00
24 Cleanup continuation
25 Recess 4:30pm
26 Luau 6:45pm
27 Call to Order, January, 18 9:00am Paddle Room
28 Cleanup continuation
29 Coffee Break 10:30
30 Cleanup continuation
31 Lunch, 12:00 Voyage Room Restaurant
32 Cleanup continuation
33 Recess, 3:00pm
34 Call to Order, January, 18 7:00pm
35 Cleanup continuation
36 Adjournment
∂10-Jan-89 0905 X3J13-mailer FTP access to compiler issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Jan 89 09:05:26 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA03597; Tue, 10 Jan 89 10:04:18 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11488; Tue, 10 Jan 89 10:04:15 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901101704.AA11488@defun.utah.edu>
Date: Tue, 10 Jan 89 10:04:14 MST
Subject: FTP access to compiler issues
To: x3j13@sail.stanford.edu
Copies of the pending issues from the compiler committee are available
for anonymous FTP from cs.utah.edu (128.110.4.21). Look in directory
pub/cl-compiler/pending.
There are also copies of the issues that were passed at the last meeting
in directory pub/cl-compiler/passed.
-Sandra
-------
∂10-Jan-89 0935 X3J13-mailer **DRAFT** issue COMPILED-FUNCTION-REQUIREMENTS, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Jan 89 09:34:53 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA05135; Tue, 10 Jan 89 10:33:45 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11507; Tue, 10 Jan 89 10:33:41 MST
Date: Tue, 10 Jan 89 10:33:41 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901101733.AA11507@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue COMPILED-FUNCTION-REQUIREMENTS, version 2
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILED-FUNCTION-REQUIREMENTS
References: CLtL p. 32, 76, 112, 143, 438-439
Issue FUNCTION-TYPE (passed)
Issue COMPILER-LET-CONFUSION
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue LOAD-TIME-EVAL
Category: CLARIFICATION
Edit History: V1, 3 Jan 1989 Sandra Loosemore
V2, 10 Jan 1989, Sandra Loosemore (additional proposal)
Status: **DRAFT**
Problem Description:
There is confusion about what functions might be or must be of type
COMPILED-FUNCTION, and what attributes must be true of
COMPILED-FUNCTIONs. Is the distinction between COMPILED-FUNCTIONs and
other functions only one of representation, or can user programs infer
anything about COMPILED-FUNCTIONs? Are implementations required to
distinguish between compiled and non-compiled functions?
CLtL defines a COMPILED-FUNCTION as "a compiled code object". (Issue
FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
FUNCTION.) Although it is not explicitly stated, CLtL implies that
compiled code must conform to certain rules; in particular, it states
that all macros are expanded at compile time, and specifies different
behavior for the COMPILER-LET and the EVAL-WHEN special forms
depending on whether they are interpreted or compiled.
The description of COMPILE in CLtL says that "a compiled-function object
[is] produced". It is not clear to everyone whether this implies that
COMPILED-FUNCTION-P must be true of such functions. CLtL says nothing
about whether functions defined in files compiled with COMPILE-FILE and
subsequently loaded must be of type COMPILED-FUNCTION.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:
(1) Clarify that if a function is of type COMPILED-FUNCTION, the
following are guaranteed about the function:
- All macro calls within the function have already been expanded
and will not be expanded again when the function is called.
(See CLtL p. 143.)
- Nested COMPILER-LETs will not bind any variables when the function
is called (CLtL p. 112).
- If the function contains nested EVAL-WHENs, only the LOAD (and not
the EVAL) situation is applicable.
- If the function contains nested LOAD-TIME-VALUE forms, these have
already been pre-evaluated and will not be evaluated again when
the function is called.
(2) Implementations are free to classify all functions as
COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
listed in item (1). It is also permissible for interpreted FUNCTIONs
to satisfy the above criteria but not be distinguished as
COMPILED-FUNCTIONs.
(3) Clarify that COMPILE always produces an object of type
COMPILED-FUNCTION. Clarify that when functions are defined in a
file which is compiled with COMPILE-FILE, and the compiled file is
subsequently LOADed, objects of type COMPILED-FUNCTION result.
Rationale:
This proposal assigns some specific properties to compiled functions.
It also states what many people believe to be the minimum functionality
required of a compiler.
Proposal COMPILED-FUNCTION-REQUIREMENTS:FLUSH:
(1) Remove the type specifier COMPILED-FUNCTION and the predicate
COMPILED-FUNCTION-P from the language.
(2) Clarify that functions produced by COMPILE, or defined in a file
that is compiled with COMPILE-FILE and then LOADed must satisfy
the same requirements listed in section (1) of the previous proposal.
Rationale:
Distinguishing between compiled and non-compiled functions is of
little use to portable programs.
This proposal states what many people believe to be the minimum
functionality required of a compiler.
Current Practice:
It appears that most implementations currently distinguish compiled
versus non-compiled functions on the basis of representation, but it
seems unlikely that any existing implementation would have problems
with the requirements in item (1).
A-Lisp uses the same representation for both compiled and interpreted
functions and currently labels them both as COMPILED-FUNCTION, but the
implementation of COMPILED-FUNCTION-P could be easily fixed to
distinguish "real" compiled functions.
On the TI Explorer, the COMPILE function can return an object of
either type COMPILED-FUNCTION or LEXICAL-CLOSURE, where the latter
consists of two components -- an environment and a COMPILED-FUNCTION.
There is confusion about whether microcoded functions should be
considered compiled or not.
Cost to implementors:
Unknown, but probably small for either proposal. Under proposal
FLUSH, implementations could continue to do whatever they do now with
the COMPILED-FUNCTION type as an extension.
Cost to users:
Probably minimal. Since the COMPILED-FUNCTION type specifier is
currently ill-defined, it is hard to imagine that existing programs
can portably rely on any interpretation of what it means that is
inconsistent with what is presented here.
Benefits:
The specification of what the compiler must do is made more explicit.
Discussion:
The FIXNUM and BIGNUM types were also defined in CLtL solely on the
basis of distinguished representations, and that this definition has
proved inadequate for just about all portable usages of these type
specifiers. Defining COMPILED-FUNCTION solely on the basis of
distinguished representation seems like a bad idea.
David Gray notes:
We make good use of the type COMPILED-FUNCTION in our implementation,
but all of the accessor functions for objects of that type are
non-standard, which makes me wonder if it might be best to just remove
this type from the standard along with BIGNUM.
One possible use of the COMPILED-FUNCTION type is in declarations. Are
there any implementations which have a distinguished representation for
COMPILED-FUNCTIONs, that use type declarations to compile calls to these
functions more efficiently?
∂10-Jan-89 1238 X3J13-mailer summary of open cl-compiler issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Jan 89 12:38:10 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA13596; Tue, 10 Jan 89 13:36:57 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11651; Tue, 10 Jan 89 13:36:53 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901102036.AA11651@defun.utah.edu>
Date: Tue, 10 Jan 89 13:36:50 MST
Subject: summary of open cl-compiler issues
To: x3j13@sail.stanford.edu
Here is a complete list of all open cl-compiler issues, as of today
(10 Jan 1989).
Non-draft issues distributed prior to January meeting:
ALLOW-LOCAL-INLINE (v4)
Interpretation of INLINE/NOTINLINE declarations.
COMPILE-ENVIRONMENT-CONSISTENCY (v3)
What kinds of things can/must the compiler "wire in" to the code
it compiles?
DEFCONSTANT-SPECIAL (v3)
Does DEFCONSTANT proclaim the variable SPECIAL?
LOAD-TIME-EVAL (v8)
Add a new special form similar to what #, does.
SHARP-COMMA-CONFUSION (v2)
Remove the #, read macro.
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS (v8)
Clarify compile-time side effects of various defining macros.
CONSTANT-MODIFICATION (v2)
It's an error to destructively modify quoted constants.
Draft issues distributed prior to January meeting:
COMPILER-DIAGNOSTICS (v8)
Clarify status and handling of errors and warnings signalled during
compilation.
COMPILER-VERBOSITY (v5)
Mechanisms for controlling progress messages issued by the compiler.
CONSTANT-COMPILABLE-TYPES (v5)
What types of objects can appear as quoted or self-evaluating constants
in compiled code?
CONSTANT-CIRCULAR-COMPILATION (v5)
Must circular or recursive objects be compiled correctly? Must the
compiler preserve sharing of substructures?
CONSTANT-COLLAPSING (v5)
Should the compiler be allowed to "collapse" or coalesce constants
that satisfy a more general equivalence relationship than EQUAL?
QUOTE-MAY-COPY (v4)
May COMPILE and EVAL construct equivalent copies of quoted or
self-evaluating constants, or must constants share structure with
the source code for the program? Do the constraints on what objects
are valid constants also apply to COMPILE and EVAL, or only to
COMPILE-FILE?
EVAL-WHEN-NON-TOP-LEVEL (v4)
What does EVAL-WHEN mean when it appears in non-top-level locations?
DEFINING-MACROS-NON-TOP-LEVEL (v7)
Are defining macros such as DEFUN meaningful in non-top-level locations?
COMPILED-FUNCTION-REQUIREMENTS (v2)
What does the COMPILED-FUNCTION type imply? Do COMPILE and
COMPILE-FILE construct COMPILED-FUNCTIONs?
Other issues under discussion but not yet distributed:
COMPILER-LET-CONFUSION (v5)
The description of COMPILER-LET in CLtL is broken -- should we fix
it or eliminate it entirely?
MACRO-ENVIRONMENT-EXTENT (v1)
Do environment objects received as the &ENVIRONMENT argument to a
macro have dynamic or indefinite extent?
MACRO-ENVIRONMENT-CREATOR (v1)
How can code-walkers add the macro definitions in a MACROLET to
an environment object suitable for passing to MACROEXPAND?
DEFCONSTANT-NOT-WIRED (v5)
Add a way to declare a constant like DEFCONSTANT, but without giving
the compiler permission to "wire in" the value into compiled code.
Issues where proposals have been submitted but not followed up on:
CONSTANT-ARRAY-ATTRIBUTES
What attributes of constant arrays are preserved by compilation?
Probably subsumed by CONSTANT-COMPILABLE-TYPES.
COMPILE-FILE-ENVIRONMENT
Clarify that macro environment objects contain information about
whether it was built by the compiler or interpreter.
Superseded by issue SYNTACTIC-ENVIRONMENT-ACCESS, unless that issue
has died.
DEFCONSTANT-VALUE
When is the value form to DEFCONSTANT evaluated?
Subsumed by issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS.
DEFINE-OPTIMIZER
Provide a macro-like way of specifying source-to-source transformations.
Waiting for revisions (Pitman)
FILE-COMPILATION
same issue as CONSTANT-COMPILABLE-TYPES?
PROCLAIM-ETC-IN-COMPILE-FILE
Are top-level calls to PROCLAIM handled specially by the compiler?
Waiting for resolution of related cleanup issues (DEFPACKAGE,
IN-PACKAGE-FUNCTIONALITY)
SYNTACTIC-ENVIRONMENT-ACCESS
Provide accessors and constructors for lexical environment objects.
Waiting for new writeup (Benson)
WITH-COMPILATION-UNIT
Provide a way to compile a group of files as a unit for the purposes
of error messages.
Waiting for revisions to existing proposal (Pitman)
-------
∂10-Jan-89 1543 X3J13-mailer Issue: APPLYHOOK-ENVIRONMENT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:43:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 15:42:31 PST
Date: 10 Jan 89 15:42 PST
From: masinter.pa@Xerox.COM
Subject: Issue: APPLYHOOK-ENVIRONMENT (Version 2)
To: x3j13@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
line-fold: no
cc: masinter.pa@Xerox.COM
Message-ID: <890110-154231-6930@Xerox>
In addition to the many issues on the ballot, there are
a number of other issues that are in various states of
completion. If we have time, we may be able to consider
some of these.
!
Forum: Cleanup
Issue: APPLYHOOK-ENVIRONMENT
References: APPLYHOOK (CLtL p. 323)
Category: CHANGE
Edit history: Masinter, 6-Jan-89, Version 1
Masinter, 10-Jan-89, Version 2
Problem description:
The function APPLYHOOK is documented to take an optional environment
argument. CLtL says "Furthermore, the env argument is used as the lexical
environment for the operation; env defaults to the null environment."
However, there is no way that the lexical environment can effect the way in
which APPLYHOOK processes its arguments; it merely calls the specified
function, and function call is not affected by lexical environments. (The
"function" argument to APPLYHOOK is a function object.)
This has been regularly a source of confusion for programmers encountering
APPLYHOOK.
The comments also apply to functions bound to *APPLYHOOK*, i.e., under the
description of *APPLYHOOK* on p.322, the following
"The non-NIL value of *APPLYHOOK* should be a function that takes
three arguments, a function, a list of arguments and an
environment..."
Proposal (APPLYHOOK-ENVIRONMENT:REMOVE-ENV):
Remove the optional "ENV" argument to APPLYHOOK. Specify
that the non-NIL value of *APPLYHOOK* should be a function that takes
two arguments, a function and a list of arguments.
Rationale:
Removes a very minor wart.
Current practice:
Most implementations accept an extra argument and then ignore it.
Cost to Implementors:
Remove optional ENV argument from APPLYHOOK and any code that passes one to
APPLYHOOK.
Cost to Users:
Remove any ENV argument passed to APPLYHOOK. Fix any *APPLYHOOK*
functions to only take two arguments (or to make the third argument optional.)
Cost of non-adoption:
Continued confusion.
Performance impact:
None
Benefits:
Removes a wart.
Esthetics:
Minor improvement.
Discussion:
This was discussed on the Common Lisp mailing list several years ago, but
slipped through the cracks.
∂10-Jan-89 1555 X3J13-mailer Issue: COMPLEX-ATAN-BRANCH-CUT, (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:55:49 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JAN 89 15:53:55 PST
Date: 10 Jan 89 15:53 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: COMPLEX-ATAN-BRANCH-CUT, (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890110-155355-6963@Xerox>
!
Forum: Cleanup
Issue: COMPLEX-ATAN-BRANCH-CUT
References: CLtL p.208, 212
Related issues: IEEE-ATAN-BRANCH-CUT
Category: CHANGE
Edit history: Version 1, 13-Dec-88, Steele
Problem description:
The formula that defines ATAN results in a branch cut that is at
variance with the recommendations of Prof. W. Kahan and with the
implementations of that function in many computing systems and
calculators.
Proposal (COMPLEX-ATAN-BRANCH-CUT:TWEAK):
Replace the formula
arctan z = - i log ((1+iz) sqrt (1/(1+z↑2)))
with the formula
arctan z = (log (1+iz) - log (1-iz)) / (2i)
This leaves the branch cuts pretty much in place; the only change is
that the upper branch cut (on the positive imaginary axis above i)
is continuous with quadrant I, where the old formula has it continuous
with quadrant II.
Examples:
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Current
(atan #c(0 2)) => #c(1.57... -0.549...) ;Proposed
Note: 1.57... = pi/2, and 0.549... = (log 3)/2.
Rationale:
Compatibility with what seems to be becoming standard practice.
Current practice:
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Symbolics CL
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Allegro CL 1.1 (Macintosh)
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Sun-4 CL 2.1.3 of 10-Nov-88
(atan #c(0 2)) => #c(1.57... -0.549...) ;Sun CL 2.0.3 of 30-Jun-87
(atan #c(0 2)) => #c(1.57... 0.549...) ;KCL of 3-Jun-87
Note that in KCL the upper branch cut is thus continuous with
quadrant I, but its lower branch cut is continuous with quadrant III!
Cost to Implementors:
ATAN must be rewritten. It is not a very difficult fix.
Cost to Users:
It is barely conceivable that some user code could depend on this.
Note that the proposed change invalidates the identities
arctan i z = i arctanh z
and arctanh i z = i arctan z
on the upper branch cut.
The compatibility note on p. 210 of CLtL gave users fair warning that
a change of this kind might be adopted.
Cost of non-adoption:
Incompatibility with HP calculators.
Benefits:
Numerical analystsmay find the new definition easier to use.
Esthetics:
A toss-up, except to those who care.
Discussion:
Steele has sent a letter to W. Kahan at Berkeley to get any last
comments he may have on the matter.
Paul Penfield of MIT, after whose article the Common Lisp branch
cuts were originally patterned, endorses this change.
∂10-Jan-89 1710 X3J13-mailer Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE, (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 17:09:52 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JAN 89 17:08:39 PST
Date: 10 Jan 89 17:08 PST
Sender: masinter.pa@Xerox.COM
Forum: Cleanup
Subject: Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE, (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890110-170839-7158@Xerox>
!
Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
References: DEFSTRUCT (p. 308)
Category: CHANGE
Edit history: 5-Oct-88, Version 1 by Chapman
6-Jan-89, Version 2 by Masinter
Problem Description:
It is left up to the implementation whether or not the DEFSTRUCT access
function is declared inline. Thus, some programmers write:
(PROCLAIM '(INLINE FOO-A FOO-B FOO-C))
(DEFSTRUCT FOO A B C)
in portable code in case the code is run in an implementation where
the INLINE proclaimation is meaningful but not the default for
DEFSTRUCT accessors.
Proposal (DEFSTRUCT-ACCESS-FUNCTIONS-INLINE:YES)
Make it mandatory that implementations declare access functions inline.
Of course the declaration may or may not mean anything within the
particular implementation.
Rationale:
This requirement resolves user ambiguity.
Current Practice:
We've not surveyed many implementations, but apparently they
differ as to whether INLINE for defstruct accessors is the default.
Cost to implementors:
Minimal.
Cost to users:
Minimal.
Benefits:
This clarification will give users insurance that the inline declaration
has been made for the access function.
Aesthetics:
Specified is simpler than not-specified.
Performance Impact:
Small. Some programs might have different size/space characteristics.
Discussion:
We know of no implementation where such automatic inlining would
be inappropriate, even in cases where INLINE is recognized. Certainly
implementations are free to ignore INLINE proclaimations even
selectively, i.e., ignore INLINE proclaimations only for DEFSTRUCT
accessors. The major impact of this proposal is just to make it clear
that a separate (PROCLAIM '(INLINE ...)) is not necessary.
∂11-Jan-89 1433 X3J13-mailer Another DRAFT Agenda
Received: from lucid.com ([192.26.25.1]) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:33:01 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03447g; Wed, 11 Jan 89 08:58:23 PST
Received: by challenger id AA02160g; Wed, 11 Jan 89 08:54:16 PST
Date: Wed, 11 Jan 89 08:54:16 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901111654.AA02160@challenger>
To: x3j13@sail.stanford.edu
Subject: Another DRAFT Agenda
After a flurry of mail we have an updated DRAFT Agenda
Monday, January 16
7:30am - ISO discussion, Chart room
We've found copying facilities to be very expensive at hotels. We intend not
to use their facilities. Please mail copies of reports to Liz Anne's
attention at the hotel if you intend to distribute reports to the meeting.
Participants are encouraged to bring copies of reports mailed to them to the
meeting.
X3J13 Committee Meeting Agenda DRAFT
January 16 - 18, 1988
1 Call to Order, January 16, 9:00am Chart Room
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Chapter 3 CLOS, Gregor Kiczales (1 hour)
7 Coffee Break 10:30
8 Chapter 3 CLOS, Gregor Kiczales (1 hour)
9 LUNCH 12:00 Voyage Room Restaurant
10 Editorial Subcommittee Report, Kathy Chapman (1 hour)
11 Compiler Subcommittee, Sandra Loosemore (2 hours)
12 Recess 3:00
13 Call to Order, 8:00pm
14 Iteration Subcommittee Report, Jonl White (30 minutes) 89-004
15 Other Subcommittee Reports
16 Recess 10:00
17 Call to Order, January 17, 9:00am Chart Room
18 Other Subcommittee Reports
19 Coffee Break 10:30am
20 Cleanup Subcommittee, Larry Masinter
21 Lunch 12:00 Voyage Room Restaurant
22 Cleanup continuation
23 Break 3:00
24 Cleanup continuation
25 Recess 4:30pm
26 Luau 6:45pm
27 Call to Order, January, 18 9:00am Paddle Room
28 Cleanup continuation
29 Coffee Break 10:30
30 Character Subcommittee Report, Thom Linden (1 hour)
31 Lunch, 12:00 Voyage Room Restaurant
32 Cleanup continuation
33 Recess, 3:00pm
34 Call to Order, January, 18 7:00pm
35 Cleanup continuation
36 Adjournment
∂11-Jan-89 1649 X3J13-mailer Issue: IEEE-ATAN-BRANCH-CUT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 16:49:27 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 16:43:33 PST
Date: 11 Jan 89 16:43 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: IEEE-ATAN-BRANCH-CUT (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-164333-11134@Xerox>
!
Forum: Cleanup
Issue: IEEE-ATAN-BRANCH-CUT
References: CLtL p.203-214
Related issues: COMPLEX-ATAN-BRANCH-CUT
Category: CHANGE
Edit history: Version 1, 13-Dec-88, Steele
Version 2, 11-Jan-89, Masinter (1st => 3rd person)
Problem description:
If an implementation provides a floating-point minus zero as well as a
floating-point plus zero, most notably as in IEEE 754 floating-point
arithmetic, then slight adjustments in the branch cuts of transcendental
functions are appropriate.
If there is a minus zero and a plus zero, then *no* complex number
is actually "on the axis" whether real or imaginary. Instead,
numbers of the form x+0i and x-0i straddle the real axis, and those
of the form 0+xi and -0+xi straddle the imginary axis. Branch cuts
that lie on the axes therefore run between such numbers, and directions
of continuity are not an issue.
Proposal (IEEE-ATAN-BRANCH-CUT:SPLIT):
Redefine the branch cut for two-argument ATAN, covering
the cases where there is or is not a minus zero, and then redefine *all*
other functions that have branch cuts in terms of two-argument ATAN.
Specifically, first define PHASE in terms of two-argument ATAN,
and complex ABS in terms of real SQRT (which has no branch cut problems);
then define complex LOG in terms of PHASE, ABS, and real LOG; then define
complex SQRT in terms of LOG; and then define all others in terms of these.
In this propoal Lisp expressions should be taken as mathematical
formulas that actually are implemented in other ways for improved accuracy.
(1) If there is no minus zero, two-argument ATAN behaves as in CLtL.
If there is a minus zero, then some cases are modified:
Condition result
y=+0 x>0 +0
y=-0 x>0 -0
y=+0 x<0 +pi
y=-0 x<0 -pi
y=+0 x=+0 +0
y=-0 x=+0 -0
y=+0 x=-0 +pi
y=-0 x=-0 -pi
The range of two-argument atan therefore includes -pi in this case.
Note that the case y=0 x=0 is an error in the absence of minus zero,
but is defined in the presence of minus zero.
(2) (PHASE X) = (ATAN (IMAGPART X) (REALPART X)), as before, but now
the range of PHASE may include -PI if there is a minus zero.
(3) (ABS X) = (SQRT (+ (* (REALPART X) (REALPART X))
(* (IMAGPART X) (IMAGPART X)))), as before
(4) (LOG X) = (COMPLEX (LOG (ABS X)) (PHASE X))
(5) (SQRT X) = (EXP (/ (LOG X) 2))
(6) For EXPT, ASIN, ACOS, ATAN, ASINH, ACOSH, ATANH use the formulas
in CLtL pp. 211-213, but use the formulas (1-5) above as the
definitions of LOG and SQRT in order to determine the branch cuts
properly.
Examples:
(LOG #c(-1.0 +0.0)) => #c(0.0 3.14159...) ;Current
(LOG #c(-1.0 -0.0)) => #c(0.0 3.14159...) ;Current
(LOG #c(-1.0 +0.0)) => #c(0.0 3.14159...) ;Proposed (= current)
(LOG #c(-1.0 -0.0)) => #c(0.0 -3.14159...) ;Proposed (conjugate)
Rationale:
The current specification ignores some natural consequences of IEEE
floating-point arithmetic. The proposed specification produces results
more natural to that arithmetic.
Current practice:
Of implementations that support a minus zero that I have checked,
such as Sun-4 CL 2.1.3 of 10-Nov-88 and Symbolics CL, all follow
the current CLtL specification.
The IEEE trig library atan2 routine written by K.C. Ng (with the advice
or supervision of W. Kahan, I believe), and distributed with BSD UNIX
(it is file /usr/src/usr.lib/libm/IEEE/atan2.c on my machine) follows
this proposal for treatment of minus zero.
Cost to Implementors:
Some of the trig routines will require some rewriting. Probably certain
tests that are now written using ZEROP need to be rewritten to use
FLOAT-SIGN instead.
Cost to Users:
It is barely conceivable that some user code could depend on this.
Probably there is no cost.
The compatibility note on p. 210 of CLtL gave users fair warning that
a change of this kind might be adopted.
Cost of non-adoption:
Unnatural treatment of some functions on machines supporting IEEE
floating-point arithmetic.
Benefits:
Natural treatment, etc.
Esthetics:
A toss-up, except to those who care.
Discussion:
Steele has sent a letter to W. Kahan at Berkeley to get any last
comments he may have on the matter.
∂11-Jan-89 1703 X3J13-mailer Issue: LISP-PACKAGE-NAME, (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 17:03:01 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 16:52:58 PST
Date: 11 Jan 89 16:52 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: LISP-PACKAGE-NAME, (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-165258-11168@Xerox>
!
Issue: LISP-PACKAGE-NAME
References: 11.6 Built-in Packages (pp181-182)
Category: CHANGE
Edit history: 22-Dec-88, Version 1 by Pitman
Problem Description:
Since ANSI Common Lisp will differ from the Common Lisp described by CLtL,
it will not be possible to have support for both in the same Lisp image
if ANSI Common Lisp insists on placing its functionality in the package
named LISP.
Further, use of the name unqualified name LISP by the ANSI Common Lisp
community is inconsistent with ANSI's expressed position to ISO that
the term "LISP" names a language family rather than a specific dialect
within that family.
Proposal (LISP-PACKAGE-NAME:COMMON-LISP):
Define that ANSI Common Lisp uses the package name COMMON-LISP, not LISP.
Define that the COMMON-LISP package has nickname CL.
Since some symbols (e.g., T, NIL, and LAMBDA) might have to be shared
between COMMON-LISP and LISP in implementations simultaneously supporting
both, clarify that the initial symbols specified by ANSI Common Lisp as
belonging in the COMMON-LISP package need not have a home package of
Common-Lisp.
Test Case:
In an implementation supporting CLtL's LISP package and
the ANSI Common Lisp CL package proposed here:
(EQ 'LISP:T 'CL:T)
=> not specified, due to this proposal, but probably T
(EQ 'LISP:CAR 'CL:CAR)
=> not specified, due to this proposal, but probably T
(EQ 'LISP:FUNCTIONP 'CL:FUNCTIONP)
=> not specified, due to this proposal, but since FUNCTIONP is
changed incompatibly between CLtL (LISP) and CL (ANSI), there
are good reasons why this might return NIL.
(SYMBOL-PACKAGE 'CL:T)
=> not specified, due to this proposal. Perhaps #<Package CL>,
perhaps #<Package LISP>, or perhaps something implementation-specific.
(SYMBOL-PACKAGE 'LISP:T)
=> not specified, not due to this proposal, but because CLtL didn't
specify this explicitly.
Rationale:
In practice, some implementations will have very legitimate reasons for
wanting to Lisp dialects to be coresident. As it stands, they will have
little other choice than to make the two use different packages, and so
will be forced to be incompatible with one or the other dialect unless
we choose a different package name for the one dialect for which there
is currently no existing code.
Not only is this important the CLtL and ANSI Common Lisp communities, but
also, if we continue to use the name LISP, it sends a signal to the ISO
Lisp community that the "latest and greatest" Lisp should use the generic
name LISP, and they may try to use it as well. If ISO Lisp turns out to
be very different than ANSI Common Lisp, there may be motivation down the
line for having ISO Lisp and ANSI Common Lisp co-resident, and conflicts
will inevitably arise if both want to use the name LISP. This will almost
certainly lead to a confrontation where one Lisp dialect tries to force
the other out by the artificial means of asserting its right to this
generic name. Choosing a name which compatibly admits the option of
introducing other dialects into the environment at a later date without
conflict is a good way to avoid a class of potential problems.
Although there are a few problems which could come up due to the symbol
package of initial symbols being unspecified, experience with
implementations that do this suggests that they are very few.
Problems occur only in the rare circumstance that all of the following
conditions are met:
- A symbol S on the LISP package but with home package H (that is not "LISP")
is shadowed in some package P of implementation A.
- A program F in package P uses the shadowed symbol H:S by an explicit
LISP: or H: package qualification. (Only the case of using "LISP:" is
interesting, of course, since if H were named explicitly, we would be
outside the bounds of portable code).
- The program F, referring to H:S, is printed out in implementation A
while using package P (or some other package that shadows S, so that
the H package qualifier appears explicitly) and an attempt is made to
re-read it in implementation B.
- Implementation B has no package named H, has a package named H but no
external symbol named S, or has a package named H with external symbol
S but the symbol H:S has different semantics in implementation B than
it did in implementation A.
In practice, this hardly ever happens. It would happen even less if
programmers were explicitly alerted that it was a potential problem they
needed to guard against.
Current Practice:
Symbolics Genera already has a package named COMMON-LISP with nicknames
CL and LISP. As such, this would be an incompatible change for Genera.
Cost to Implementors:
Small.
In some cases, this may even have `negative cost' because it will provide
implementors a way of avoiding incompatible changes to released operators.
Cost to Users:
Small.
In some cases, this may even have `negative cost' because existing code
would be able to continue to run in implementations which chose to support
both CLtL's LISP and ANSI Common Lisp's CL packages, thereby allowing
developers to put off a massover changeover, perhaps doing the transition
more incrementally.
Cost of Non-Adoption:
Implementations trying to support multiple dialects in the same environment
would be forced to violate one or the other spec.
Worse, different implementations faced with the same set of hard choices
about which spec to violate in order to concurrently support two dialects
might not make the same choices, leading to even more gratuitous
incompatibility.
ANSI's position in ISO that we are not trying to legislate the meaning of
-the- LISP dialect would be weakened.
Benefits:
Needless incompatibility would be avoided in a variety of situations.
Aesthetics:
Failing to specify the home package of symbols in the LISP and CL packages
seems unaesthetic because it appears to diminish print/read invertability,
but as observed above, that case is rare.
Failiing to specify a way in which lisp dialects can be co-resident is also
unaesthetic because in practice implementors with a need to do this will do
so whether the standard allows them or not, and it will be a source of
severe divergence among implementations.
Discussion:
Symbolics Genera offers two co-resident dialects of Lisp: Zetalisp and
Symbolics Common Lisp. The Symbolics Cloe development environment adds
a third co-resident dialect, making an environment in which two differing
Common Lisp dialects (Symbolics Common Lisp and Cloe) must cooperate.
Already in Cloe it is not possible for the home package to contain
package "LISP" since Cloe's concept of what the "LISP" package is differs
from Genera's concept of what the "LISP" package is, yet they are forced
by efficiency constraints to share the same symbol. It is Pitman's belief,
based on extensive experience with Cloe, that failure to pass this proposal
(or something very like it) will lead to all sorts of trouble for Common
Lisp users and implementors down the road.
Pitman strongly supports this proposal.
Additional comments:
Is it permissible for implementations to define
"LISP" as a nickname for this package, for the
sake of backward compatibility?
Anyone wanting to make LISP a nickname could just as well create a LISP
package which simply imported the appropriate symbols from the CL package.
With only modest additional effort, they could try to make new symbols where
feasable (especially for most functions) and put borrowed functions plopped
in their function cells. The amount of additional storage is small (compared
to implementing a whole new lisp), but it would leave open the possibility for
users upgrading the level of compatibility without hurting the core
system. eg, if I wanted APPEND to signal an error on dotted lists, I
would not consider redefining the system's APPEND for fear of breaking
the world, but if they told me that nothing depended on LISP other than
compatibility code, I might feel ok about redefining (or doing
SHADOWING-IMPORT of LISP:APPEND on a per-implementation basis (with
appropriate sharp conditionals)) in order to up the level of
compatibility.
In fact, though, my guess is that implementations which are not going to
do a serious compatibility effort are better off leaving the package
missing. My experience has been that customers are often happier growing
their own compatibility [or getting it from a public library] than being
stuck with something which really doesn't do what they want but which
seals off the place in the namespace which they needed in order to do
their own thing.
∂11-Jan-89 2008 X3J13-mailer Ballot (finally)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 11 Jan 89 20:04:05 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa01484; 12 Jan 89 3:54 GMT
Date: Thu, 12 Jan 89 03:57:03 GMT
Message-Id: <18811.8901120357@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Ballot (finally)
To: masinter.pa@xerox.com, x3J13@sail.stanford.edu
In-Reply-To: masinter.pa@com.xerox's message of 12 Dec 88 18:16 PST
Cc: richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK,
rhr%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
This is the official vote for the University of Edinburgh.
Y ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
Y ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
Y CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Version 5, 5-Dec-88, Mailed 5 Dec 88
Y CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
Y DECLARATION-SCOPE:NO-HOISTING
N DECLARATION-SCOPE:LIMITED-HOISTING
Version 4, 15-Nov-88, Mailed 9-Dec-88
NO brings LET closer to application of LAMBDA-expressions.
The "en passant" capture in LIMITED is a bit too stange.
A DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Version 4, 5-Dec-88, Mailed 5-Dec-88
N DECLARE-TYPE-FREE:ALLOW
Y DECLARE-TYPE-FREE:LEXICAL (v 9)
Version 8, 7-Dec-88, Mailed 9-Dec-88
LEXICAL is consistent with SYMBOL-MACROLET-DECLARE:ALLOW.
A DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
Y DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
I DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
If ammended as suggested by Kim Barrett.
Y DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
Y DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
A DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
A DESCRIBE-INTERACTIVE:NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
Y DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
I voted yes beacuse subforms can be dotted, but I don't really like it.
I EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
If the EQUALP problems are cleared up.
N EXIT-EXTENT:MINIMAL
Y EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
Y EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
Y FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
N FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Version 4, 7-Dec-88, Mailed 12-Dec-88
I prefer to retain a name for the non-fixnums.
I favor retaining FIXNUM because it allows me to do a useful thing
(request integers that can be handled with a certain degree of
efficiency) in the same way in all implementations that provide it.
Note that there is a large class of implementations in which fixnums
are large enough to contain the address part of a pointer and so
can be used in every case where I count objects or index structures.
Again, I prefer to be able to use the same declaration in all of these
implementations.
Not all code is meant to be portable to all Common Lisps.
Moreover, if efficiency is my concern, an explicit subrange is
actually less portable, because I cannot specify its representation.
Y FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
Y FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
Y FUNCTION-COMPOSITION:NEW-FUNCTIONS
I FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
C-AND-A if NEW-FUNCTIONS fails.
Y FUNCTION-DEFINITION:FUNCTION-SOURCE
Version 2, 09-Dec-88 , Mailed 9 Dec 88
Y FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
I think the explanation of exactly what changes could be clearer,
and I am not completely sure I understand it.
Y FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
Y GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
I agree with the remark that the tests imply EQ will hold
when that is not actually guaranteed.
N HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Version 7, 8-Dec-88, Mailed 9-Dec-88
I might be convinced to change my mind, but right now I think this
proposal is premature. There is nothing very like it in the rest
of CL, and it would make more sense to wait until the need for it
has been more firmly established. I am also bothered by the use
of MACROLET. Is it really the case that functions declared INLINE
would not be enough for optimization?
Y HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
I think this is an important clarification even though it may
not lead to extensive changes in practice. I disagree with the
suggestions that the proposal be shortened; but if it cannot
gather enought support as-is, it might be rearranged so as to
stress issues of correct use, such as the effects of destructive
operations on keys.
Moreover, an explanation at this level of detail removes one of
the most common objections to allowing :test arguments outside
the standard set, if accompanied by appropriate key transformation
functions, namely that the necessary constraints must first be
understood. It may therefore encourage implementors to provide
that extension, something I would like to see.
Y HASH-TABLE-TESTS:ADD-EQUALP
Version 2, 8-Dec-88, Mailed 8 Dec 88
It seems to me that SXHASH is not quite suitable for use with
EQUALP, and so I would like the key transformation function that
is used with EQUALP to made available to the user.
Y IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
At first I thought I'd make this conditional on DEFPACKAGE passing;
then I decided MAKE-PACKAGE would suffice.
Y LAMBDA-FORM:NEW-MACRO
Version 4, 22-Nov-88, Mailed 8-Dec-88
Y LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
Y LISP-SYMBOL-REDEFINITION:DISALLOW
Version 5, 22-Nov-88, Mailed 8 Dec 88
N MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
I would like any dependency on implementation-specific extensions
to be explicit.
Y MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
A NTH-VALUE:ADD
Version 4, 8-Dec-88, Mailed 8 Dec 88
NTH-VALUE does not complete the set of operations on multiple values
because it extracts only one value, so I do not think it is needed
for the sake of completeness.
Y PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
A PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
Y PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Version 1 27-Jun-88, Mailed 7 Oct 88
I can understand why someone might find the need for :UNSPECIFIC
in Unix unclear, but I think that is because it is not clear what
filenames would be parsed as pathnames with :UNSPECIFIC type [*];
:UNSPECIFIC is nonetheless useful for building pathnames directly
when you know which case you want and need a way to specify it.
[*] Does a name without "." parse as type NIL or :UNSPECIFIC?
Different Unix programs use different conventions. Some are
willing to merge in a type field, others, such as the C compiler,
leave names as-is. So the "right" answer may vary.
Y PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
Y PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
Y PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
Under this proposal, special proclamations establish a default for
a name but, because of the lexical declaration, no longer force it
to be special everywhere. It also allows the programmer to say
that a global name is intended as a variable (i.e., references to
it are not spelling mistakes) without proclaiming it special. I
think these are important changes that should be preserved even if
this proposal fails. Another important feature is that LG references
to global variables can be fast in deep-bound implementations (since
L "searches" can be compiled away) while DG references (the only
global variables we have now) first have to look in D. Finally,
the current semantics are subtly confusing, because the specialness
of global variables occasionally shows through. For all of these
reasons, I support this proposal.
I think the most controversial change is the introduction of a
separate global environment, where before the only globals were
effectively just the global end of the dynamic env. Most of the
implementation complexity stems from this change, and it is likely
that it lies behind most objections.
A reasonable fallback, if this proposal does not pass, would be
to say that variables that are proclaimed lexical can never by
given dynamic bindings. That is, the global value would be taken
after searching L or D but not both and so would effectively be
an extension of the L or D env, case by case. This would be
somewhat unfortunate, because local lexical bindings for names
proclaimed special would still make sense (because they could be
declared lexical) but we wouldn't allow local special declarations
for names proclaimed lexical. The full proposal is better.
Y RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Version 3, 9-Oct-88, Mailed 14-Oct-88
Y RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
A REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
N REST-LIST-ALLOCATION:NEWLY-ALLOCATED
Y REST-LIST-ALLOCATION:MAY-SHARE
N REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
NEWLY-ALLOCATED is cleanest, but may be too disruptive.
Y RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
Y ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
I suppose we might, instead, allow anything other than T or NIL.
That has a bit of a ternary feel to it.
[The following are mutually exclusive]
N SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
N SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
I am not yet happy with either proposal. The first seems nicer
but complicates the semantics of CL at a rather central point
and introduces nonorthogonality by allowing (SETF name) in
FUNCTION but not as the car of a form. The second looks like
a rather desperate attempt to avoid the first. Is there some
way to avoid writing names like setf:3.bar.middle.ref in the
"local function" example? (It's the 3 that looks worst.)
Y SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
Y STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
Y STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
Y STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T ="true")
How many type names do not have corresponding predicates?
Y STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==STREAM-LINE-WIDTH
LINE-POSITION ==STREAM-LINE-POSITION
PRINTED-WIDTH ==STREAM-STRING-WIDTH
Y SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
If MEMBER, AND, OR, and NOT can be handled, I'd be happier if they
were handled. This proposal is nonetheless better than the status quo.
Y SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
Goes best with DECLARE-TYPE-FREE:LEXICAL (rather than no DECLARE-
TYPE-FREE or :ALLOW). It would be unreasonable to pass this and
reject the other.
Y SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
I TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
Contents should be valid forms (including self-evaluating) or valid
tags. Duplicate tags should be an error (as in the proposal).
Y TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
Y TEST-NOT-IF-NOT:FLUSH-ALL
Y TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
I don't oppose "depreciation" instead of deletion.
The functionality of REMOVE-IF-NOT should be preserved under
another name. Perhaps DELETE-IF-NOT too.
Y TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
Y UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
Y VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂11-Jan-89 2237 X3J13-mailer Issue: SPECIAL-TYPE-SHADOWING (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 22:37:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 22:36:27 PST
Date: 11 Jan 89 22:35 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: SPECIAL-TYPE-SHADOWING (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-223627-11614@Xerox>
!
Issue: SPECIAL-TYPE-SHADOWING
References: CLtL pages 156, 158
Related issues: DECLARE-TYPE-FREE
Category: CLARIFICATION
Edit history: Version 1, 04-Nov-88 by David Gray
Problem description:
A Common Lisp user raised the question of whether something like the
following is legal:
(PROCLAIM '(TYPE NUMBER *X*))
(DEFVAR *X*)
(DEFUN FOO ()
(LET ((*X* T))
(DECLARE (TYPE SYMBOL *X*))
(BAR)))
Page 156 of CLtL says that a proclamation is "always in force unless
locally shadowed" and page 158 says type declarations "only affect
variable bindings", which might be interpreted to mean that the DECLARE
locally shadows the PROCLAIM. However, that interpretation would make
the global type proclamation useless because it could not be relied on
when compiling a function such as BAR.
Proposal SPECIAL-TYPE-SHADOWING:CLARIFY
Clarify that if there is a local type declaration for a special
variable, and there is also a global type proclamation for that same
variable, then the value of the variable within the scope of the local
declaration must be a member of the intersection of the two declared
types.
Rationale:
Some restriction on local type declarations for special variables is
needed in order for type proclamations to be meaningful. The wording
used here was chosen for consistency with proposal DECLARE-TYPE-FREE.
Current practice:
The TI, Symbolics, and Lucid implementations do not report any error
on the example above, but it isn't clear that they really do anything
with type declarations for special variables anyway.
Cost to Implementors:
This is unlikely to require a change in any current implementation.
Cost to Users:
Anyone who has written code like the example above would have to
modify it if compilers started enforcing this restriction.
Cost of non-adoption:
A minor ambiguity in the language specification that could confuse
users.
Performance impact:
None.
Benefits:
A clearer definition of the meaning of type declarations for special
variables.
Discussion:
This is obviously very closely related to issue DECLARE-TYPE-FREE, but
this is an ambiguity in the existing language that should be resolved
even if the language extension of proposal DECLARE-TYPE-FREE is not
accepted. Note also that DECLARE-TYPE-FREE makes no mention of type
proclamations.
Other possible resolutions of the ambiguity would be to either rule
out use of local type declarations for special variables, or to say
that the local type must be a subtype of the global type.
∂11-Jan-89 2233 X3J13-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 22:33:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 22:32:40 PST
Date: 11 Jan 89 22:30 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-223240-11606@Xerox>
A more general version of this was introduced by Touretzky but
it was rejected by X3J13. This has much more restricted proposal.
!
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261), COERCE (p51)
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky (option GENERALIZED)
28-Apr-87, Version 2 by Pitman (add option MODIFIED)
26-Oct-87, Version 3 by Masinter (remove MODIFIED)
11-Nov-87, Version 4 by Masinter (respond to comments)
05-Feb-88, Version 5 by Masinter
06-Oct-88, Version 6 by Pitman
(revert to version 2, flush GENERALIZED option
-- which was rejected by X3J13 -- and resurrect MODIFIED)
Description:
Common Lisp provides many useful operations on lists and vectors which
don't apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can
REPLACE the contents of one vector with another, but one can't do this
for arrays. One can verify that EVERY element of a vector has some
property, but one can't do this for arrays. And so on.
The programmer who wishes to use arrays instead of vectors must give up
most of the useful tools CLtL provides for manipulating sequences, even
though there is no intuitive reason why operations like FILL, REPLACE,
and EVERY shouldn't work on arrays.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED):
Common Lisp already provides a facility called "displaced arrays"
which can be used to overlay one array on top of a portion of another,
even if the two are of different ranks, so that the two share storage.
Emphasize this as a way of explaining the behavior of sequence
functions on certain arrays.
Modify the definition of COERCE to allow the coercion of an array to
a vector and vice versa. In keeping with p51 of CLtL, it should be an
error if the result type has a different number of elements than the
object being coerced.
Extend the definitions of sequence functions that either return their
argument sequences, return sequences which are the same shape as their
argument, or return non-sequences so that they also allow arrays iff
their action is conceptually independent of the shape of the array.
The affected functions are COUNT, SOME, EVERY, NOTANY, NOTEVERY,
FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP.
Expressly forbid arrays as arguments to other sequence functions.
These other functions are LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH,
MISMATCH, REVERSE, NREVERSE, SORT, MAP, SUBSEQ, COPY-SEQ, CONCATENATE,
MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Rationale:
This proposal would expand rather than interfere with existing practice.
Since displaced arrays are already part of Common Lisp, the cost of the
proposed changes would be very low.
If the change is not adopted, Common Lisp programmers who wish to use
arrays will have two choices. Either they must write nested DO loops
every time they want to perform an array operation equivalent to FILL,
REPLACE, etc., or else they can build displaced vectors by hand and
pass them to the sequence functions when necessary.
This proposal extends certain sequence functions in some interesting
ways without committing us to a theory of how arrays and sequences
relate that everyone may not be happy with right now.
Cost to Implementors:
This would involve a lot of changes to functions, but all of them
presumably minor. The presence of displaced arrays in the language
already guarantees that the internal storage format needed to back
up these proposed changes is already in place.
Benefits:
Users of arrays do not have to use home-grown utilities to duplicate
functionality already primitively provided to users of arrays. The
sequence functions become useful in a variety of new situations.
Cost to Users:
This change is `upward compatible.' User code should run unmodified.
Aesthetics:
This extends certain existing sequence functions to allow arrays
as arguments in a fairly non-controversial way, leaving aside the
larger issue of whether and how to generalize the other sequence
functions.
Current Practice:
Probably no one implements this now.
Discussion:
A more general version of this was introduced by Touretzky but
it was rejected by X3J13.
The members of the Cleanup committee expressed interest in the ideas
behind this proposal but weren't sure they could accept it in the
proposed form. A rewrite to separate some of the issues more clearly
was solicited. Rees suggested this subset of Tourtezky's proposal
might be interesting.
Note that the function REDUCE is in a gray area. Many of its uses
are not position-dependent, but some are. The same argument might
be made about FIND. If people felt strongly, these too could be
extended either by fudging the conservative rule or by explicit
special case(s), but they have been omitted to be conservative.
∂11-Jan-89 2316 X3J13-mailer Issue: THE-AMBIGUITY (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 23:16:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 89 23:14:58 PST
Date: 11 Jan 89 23:14 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: THE-AMBIGUITY (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-231458-11647@Xerox>
This issue has two proposals.
!
Forum: cleanup
Issue: THE-AMBIGUITY
References: THE (page 161)
Category: CLARIFICATION
Edit history: 21-Oct-88, version 1 by Rees
11-Jan-89, version 2 by Masinter (fix typos)
Problem description:
CLtL does not explicitly say whether the type specifier in a THE
form may be any type specifier or must be a type specifier suitable
for discrimination. Although THE is decsribed as a "declaration"
form, some CL implementations have assumed that the specifier must
be for discrimination, and disallow e.g.,
(THE (FUNCTION (T T) CONS) #'CONS)
We should either say that the implementations are right, or
explicitly say that they are wrong, since this case is easily
overlooked.
Proposal (THE-AMBIGUITY:FOR-DECLARATION):
Clarify that the type specifier in
(THE type exp)
may be any valid type specifier. In the case that exp returns one
value and type is not a VALUES type specifier, (THE type exp) is
equivalent to
(LET ((g exp))
(DECLARE (TYPE type g))
g)
where "g" is a gensym.
Proposal (THE-AMBIGUITY:FOR-DISCRIMINATION):
Clarify that the type specifier in
(THE type exp)
must be a valid type for discrimination, as for TYPEP, or it must
be of the form (VALUES type*) where type* are all valid for discrimination.
Current practice:
The Symbolics Genera and VAX LISP V2.2 interpreters signal errors for
(THE (FUNCTION (T T) CONS) #'CONS),
but this may not be intentional. CLtL would seem to allow it.
Test case:
(THE (FUNCTION (T T) CONS) #'CONS),
should return the CONS function under FOR-DECLARATION,
and should be an error under FOR-DISCRIMINATION.
Cost to implementors:
Trivial cost for THE-AMBIGUITY:FOR-DISCRIMINATION; this is a compatible
restriction.
For THE-AMBIGUITY:FOR-DECLARATION, implementations that do not
already allow arbitrary type specifiers but which want to check that
the type in a THE is satisfied would have to create an internal
version of TYPEP which could manage not to signal invalid-type-specifier
errors in those situations where TYPEP would because the type is a
declaration-only one.
Cost to users:
Users of implementations that support THE-AMBIGUITY:FOR-DECLARATION
might have to remove or change some uses of THE in their code if the
opposing alternative is adopted.
Benefits:
Either way, an ambiguity in the language specification would be clarified.
Aesthetics:
THE-AMBIGUITY:FOR-DECLARATION would seem to be more consistent with
DECLARE and with the intent of THE, which is supposed to be a way to
provide information for documentation and for the benefit of compilation.
Discussion:
Rees supports THE-AMBIGUITY:FOR-DECLARATION.
Appropriate error situation terminology must be chosen for the
situation that a THE declaration (or other declaration) is
unsatisfied, but that must be done regardless of this proposal.
This proposal would suggest that a function should be added to CL to
do the checking that THE would want to do:
(PROBABLY-TYPEP object type-spec)
[terrible name of course] returns multiple values a la SUBTYPEP: T T
if the object definitely has the type, NIL T if it definitely
doesn't, and T NIL (or NIL NIL?) otherwise. Assuming that an
interpreted THE-expression actually checks types, you could almost
define this function using the condition system and EVAL. (Ugh!)
Without PROBABLY-TYPEP, a meta-circular interpreter is more
difficult to write.
If a suitable name was found for this function, the additional
functionality could be suggested as an independent proposal, since
regardless of the outcome of this issue, the functionality is still
useful for checking DECLARE's.
Various implementation mechanisms were discussed for dealing
with THE checking.
Are there any remaining type specifiers beyond the list form
of the FUNCTION type that differ between "declaration" and
"discrimination"?
"I support FOR-DECLARATION. Lucid CL has the same bug in
the interpreter as the others (a "bug" assuming FOR-DECLARATION).
TYPEP is used to check the legality of the type specifier in THE."
In considering possible ways in which the type-checking logic
for THE and DECLARE might work, don't forget things like
(the (not (function (t t) integer)) 7),
which you would want to signal an error. I don't think this can be
done with only TYPEP and conditions.
∂11-Jan-89 2346 X3J13-mailer Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 23:46:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 23:45:32 PST
Date: 11 Jan 89 23:45 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-234532-11838@Xerox>
It was believed that this issue might be controversial.
!
Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS
References: 5.1.2 Variables (CLtL pp55-56),
Slots (88-002R, p1-10)
Category: CHANGE
Edit history: 29-Nov-88, Version 1 by Pitman
Problem Description:
CLtL does not specify what happens if you attempt to call a named function
which is in fact undefined. In most implementations, it would be devastating to
actually jump to code which you had not verified to be a function, so this error
should be easily caught -- yet, CLtL does not guarantee that an error will be
signalled even in the safest, least fast OPTIMIZE settings.
CLtL (p56) specifies that "it is an error to refer to a variable that is unbound."
CLOS (p1-10) specifies that "when an unbound slot is read, the generic function
SLOT-UNBOUND is invoked. The system-supplied primary method for SLOT-UNBOUND
signals an error."
CLOS and CLtL are not in agreement on their treatment of unbound variables.
CLtL is very weak in that it guarantees no support for reliably detecting
and signalling an error when the error situation occurs, even in the safest,
least fast OPTIMIZE setting.
CLOS is very strong in that it forces detection of the error in all
situations -- even in the fastest, least safe OPTIMIZE setting.
The disparate positions for treatment of variables and slots should be
reconciled, either by finding a compromise or by justifying the apparent
inconsistency. The final story should explain function references as well.
Proposal (UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE):
Define that reading an undefined function, an unbound variable, or
an unbound slot must be detected in the highest safety setting,
but the effect is undefined in any other safety setting. That is,
- Reading an undefined function should signal an error.
- Reading an an unbound variable should signal an error.
- Reading an unbound slot should invoke the function SLOT-UNBOUND.
By ``reading an undefined function'' in the above, we mean to
include both references to the function using the FUNCTION
special form, such as F in (FUNCTION F) and references to the
function in a call, such as F in (F X).
For the case of INLINE functions (in implementations where they are
supported), it is permissible to consider that performing the inlining
constitutes the read, so that an FBOUNDP check need not be done at
execution time. Put another way, the effect of FMAKUNBOUND of a function
on potentially inlined references to that function is undefined.
Specify that the type of error signalled when an undefined function
is detected is UNDEFINED-FUNCTION, and that the NAME slot of the
UNDEFINED-FUNCTION condition is initialized to the name of the
offending function.
Specify that the type of error signalled when a unbound variable
is detected is UNBOUND-VARIABLE, and that the NAME slot of the
UNBOUND-VARIABLE condition is initialized to the name of the
offending variable.
Introduce a new condition type, UNBOUND-SLOT, which inherits from
CELL-ERROR. This new type has an additional slot, INSTANCE, which
can be initialized using the :INSTANCE keyword to MAKE-CONDITION.
Introdue a new function UNBOUND-SLOT-INSTANCE to access INSTANCE slot.
Specify that the type of error signalled by the default primary
method for the SLOT-UNBOUND generic function is UNBOUND-SLOT,
and that the NAME slot of the UNBOUND-SLOT condition is initialized
to the name of the offending variable, and that the INSTANCE slot
of the UNBOUND-SLOT condition is initialized to the offending instance.
Test Case:
(PROCLAIM '(OPTIMIZE (SAFETY 3) (SPEED 0)))
(DEFUN FOO () X)
(FOO)
>>Error: The variable X is not bound.
...
Rationale:
This makes it easier to treat slots like variables.
This makes it possible to better rely on an unbound variable error being
signalled when one has occurred.
This makes it possible to compile out useless error checking in CLOS
code where the code is debugged and the checking is redundant.
For the case of undefined functions, blindly jumping to an undefined
function is an incredibly dangerous thing to do. Every implementation
should guarantee at least some way to get error checking of undefined
functions.
Current Practice:
Until recently, Symbolics Cloe did not ever signal an error on unbound
variable, even in the safest case. The excuse was that this was a CLtL
didn't require it, but it was sometimes an impediment to debugging.
Some benchmarks for Symbolics Cloe (which currently only claims to
implement New Flavors, not CLOS) could be faster if checking for unbound
instance variables could be optimized away.
Symbolics Genera doesn't care about safety issues in variable access
because the check can be done by microcode.
Cost to Implementors:
This change does not force a change to any current implementation, except
those which do not yet signal unbound variable or undefined function errors
even in the safest setting.
Cost to Users:
This checking might slow down some code which is written for the safest
setting yet does not need this check.
Any implementation-specific code which depended on these references not
signalling would be broken. Such code was not portable, of course.
Any CLOS code which depends on SLOT-UNBOUND being called even in low safety
settings would be broken. The amount of such code at this point is likely
to be little or none. If such cases did exist, local or global changes to
safety settings would correct the problem (at some cost in speed).
Cost of Non-Adoption:
Some important error checking would not occur.
Some important optimizations could not be done.
The language would seem internally less consistent.
Benefits:
The costs of non-adoption would be avoided.
Aesthetics:
This would regularize things a little.
Discussion:
Pitman thinks this would be a good idea.
∂11-Jan-89 2357 X3J13-mailer Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 23:57:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 89 23:55:59 PST
Date: 11 Jan 89 23:55 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-235559-11843@Xerox>
Several people endorsed a proposed change from Kim Barrett
to add &ALLOW-OTHER-KEY.
This version does that, and also adds a possibly controversial
feature of allowing arguments that don't name slots but
are only used in the computation of other (default or &AUX)
values.
For discussion.
!
Forum: Cleanup
Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
References: CLtL page 316
Category: CHANGE
Edit history: 20-Sep-88, Version 1, Peck
21-Sep-88, Version 2, Masinter, minor revisions
8-Jan-89, Version 3, Masinter
Problem description:
Currently, DEFSTRUCT constructor functions can be either the default
constructor function, with *only* keyword arguments, or it can be a
so-called "By Order of Arguments" constructor function with explicitly
*no* keyword arguments. Other functions in Common Lisp allow a free
mix of required, optional, and keyword arguments.
With the current restriction, it is necessary to hand code a function that
will accept optional and keyword arguments and parse the supplied-p
variables explicitly. Even so, it is not obvious to the casual programmer
how to provide the same semantics as defstruct does with respect to default
values and the defstruct init-forms.
Proposal: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Allow &KEY keyword arguments in constructor forms of DEFSTRUCTs
and the &ALLOW-OTHER-KEYS token in addition to the &OPTIONAL,
&REST and &AUX arguments already allowed. Keyword arguments default
in a manner similar to that of &OPTIONAL arguments: if no default
is supplied in the lambda-list then the slot initform is used;
otherwise the slot is not initialized -- its initial value is
undefined.
If keyword arguments of the form ((key var) [default [svar]])
are specified, the "slot name" is matched with VAR (and not KEY).
Additional arguments that do not correspond to slot names but
are merely present to supply values used in subsequent initialization
computations are allowed.
Examples:
It should be possible to write forms like this:
(defstruct (foo (:constructor CREATE-FOO (a &optional b (c 'sea)
&key (d 2)
&aux e (f 'eff))))
(a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
(create-foo 10) => #S(foo a 10 b 2 c sea d 2 e nil f eff)
(create-foo 10 'bee 'see :d 'dee) => #S(foo a 10 b bee c see d dee e nil f eff)
In the definition:
(defstruct (frob (:constructor create-frob
(a &key (b 3 have-b) (c-token 'c)
(c (list c-token (if have-b 7 2))))))
a b c)
the c-token argument is used merely to supply a value used in the
initialization of the c slot. The "supplied-p" arguments of
keyword arguments might be of this form.
Rationale:
This is a logical extension of the specification which makes some
programming easier.
Current practice:
Many implementations signal an error if given &KEY arguments or
arguments that are not slot names. The latest version of IIM Common
Lisp allows &KEY arguments in this manner. Envos Medley
(Xerox Common Lisp) implements the proposal.
Cost to Implementors:
The modifications to allow intermixed keywords and optionals in implementations
that don't already are likely simple.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
The current situation is non-intuitive and needless restrictive.
Benefits:
Much easier for users to write the constructor function they want.
Probably implementation code would be reduced, since this would no
longer be an error.
Esthetics:
Minor improvement since it removes a needless restriction.
Discussion:
Possibly references to "By-position", "positional", and "By Order of
Arguments" constructor function might need to be changed to something else in
the standard. (They can still be called BOA-constructors, though, right? :-)
Version 2 of this proposal was on the January 1989 ballot.
----- End Forwarded Messages -----
∂12-Jan-89 0015 X3J13-mailer Issue: EQUAL-STRUCTURE, (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 00:14:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 00:12:56 PST
Date: 12 Jan 89 00:12 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE, (Version 6)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-001256-11866@Xerox>
Please see the Additional Comments at the end. Several people
noted problems with Version 5.
!
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CLARIFICATION/CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
08-Jun-88, Version 2 by Masinter (add Benson's proposal)
23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
01-Oct-88, Version 4 by Masinter (fix description)
01-Oct-88, Version 5 by Pitman (correct wording, add discussion)
11-Jan-89, Version 6 by Pitman (attempt EQUALP correction)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:MAYBE-STATUS-QUO):
Clarify that EQUAL and EQUALP do not descend any structures or data types
other than the ones explicitly specified in CLtL.
Type EQUAL Behavior EQUALP Behavior
Number uses EQL uses =
Character uses EQL uses CHAR-EQUAL
Cons descends descends
Bit-Vector descends descends
String descends descends
Pathname magic per CLtL same as EQUAL
Structure uses EQ descends
other Array uses EQ descends
Instance (Standard-Object) uses EQ descends
Hash-Table uses EQ uses EQ
Other uses EQ uses EQ
Note that the order of this table is in some cases important, with upper
entries taking priority over lower ones.
Rationale:
There seem to be as many different equality primitives as there
are applications for them. None of the possible ways of changing
EQUAL or EQUALP are flawless. Given the inability to "fix" them,
it is better to leave them alone.
Current Practice:
We are unaware of any extensions to CLtL's set of operations,
although frequently users request them.
Cost to Implementors:
Since this seems to be compatible with the status quo, none.
Cost to Users:
Same
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
There seems to be wide debate about what the proper aesthetics for
how equality should work in Common Lisp. While the status quo is not
aesthetically more pleasing than the various alternatives, aesthetic
considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
Discussion:
An earlier version of this issue with various alternatives was distributed
at the June 1988 X3J13 meeting. Since
this is a frequently raised issue, we thought we should submit it
as a clarification although there is no change to CLtL.
Options for which we considered proposals were:
- removing EQUAL and EQUALP from the standard.
- changing EQUALP to descend structures.
- changing EQUALP to be case sensitive.
- adding a :TEST keyword to EQUAL.
- making EQUAL a generic function
All of these had some serious problems.
The cleanup committee supports option STATUS-QUO.
It would be useful if descriptions of EQUAL and EQUALP contained some sort
of additional commentary alluding to the complex issues discussed here.
The following is offered to the Editorial staff as a starting point:
Object equality is not a concept for which there is a uniquely
determined correct algorithm. The appropriateness of an equality
predicate can be judged only in the context of the needs of some
particular program. Although these functions take any type of
argument and their names sound very generic, EQUAL and EQUALP are
not appropriate for every application. Any decision to use or not
use them should be determined by what they are documented to do
rather than any abstract characterization of their function. If
neither EQUAL nor EQUALP is found to be appropriate in a particular
situation, programmers are encouraged to create another operator
that is appropriate rather than blame EQUAL or EQUALP for ``doing
the wrong thing.''
!
Additional Comments to Version 6:
Version 6 attempts to fix some of the problems noted in Version 5.
There are still some open questions. Only the "Proposal"
part has been changed since Version 5; some of the costs,
benefits & other discussion is now incorrect.
Kent says:
Please read this very carefully before voting in favor of it.
There were a lot of Yes votes for the last version, which I think
had some serious bugs in it. This would be a very bad issue for
us to screw up.
Things that might need special attention:
- Moon contends that standard practice in Symbolics Lisp is
for instances to be compared using EQ under EQUALP, not by
descending. There may be performance issues involved here.
Some agreement needs to be reached.
- Neither the previous version of the proposal nor CLtL was
clear on what happens to pathnames under EQUALP. This showed
up when I converted the presentation below. That issue should
be addressed as well.
Hopefully if this version of the proposal isn't something you want to
vote yes for, at least it's in a suitable form for easy line-item
changes interactively in the meeting.
∂12-Jan-89 0104 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 01:04:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 01:02:45 PST
Date: 12 Jan 89 01:02 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-010245-11915@Xerox>
There was debate over the meaning of the phrase
"status quo" an whether this proposal reflected it.
It wasn't a very useful debate. I hope we can avoid more
of it.
!
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289)
Category: CLARIFICATION/CHANGE
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
Some of the original Common Lisp designers assert that the
:ADJUSTABLE option exists in order to allow a user to select
between getting adjustable and non-adjustable arrays.
Others of the original Common Lisp designers assert that the
:ADJUSTABLE option existed to permit implementations in which
making all arrays adjustable was very expensive to make some
arrays not adjustable.
The former camp therefore believes that :ADJUSTABLE NIL means
that the array MUST be non-adjustable. The latter camp believes
that :ADJUSTABLE NIL means that the array MIGHT be non-adjustable.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' Although this sentence
is slightly ambiguous (one might argue that :ADJUSTABLE NIL
involves supplying the :ADJUSTABLE option), it is generally
interpreted to mean that ``... with :ADJUSTABLE T.''
One problem is that since ADJUSTABLE-ARRAY-P does not predicate
whether the :ADJUSTABLE option was provided, then
ADJUSTABLE-ARRAY-P is not an appropriate predicate in all
implementations to determine whether an array is adjustable.
Technically, :ADJUSTABLE NIL could create and adjustable array
(one for which ADJUSTABLE-ARRAY-P returns true), and yet
ADJUST-ARRAY might refuse to adjust it (if it had recorded a
separate bit saying whether :ADJUSTABLE T had been specified
and used that bit for ADJUST-ARRAY). Fortunately, this problem
has not been observed to occur in practice, but it is present
in principle.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY. That expectation is violated by
legitimate implementations, since it is permissible for an
implementation to create an adjustable array even though it has
not been asked for, and since calling adjust array on such an
array "is an error" (and hence the behavior can be extended).
This perceived lack of error checking may become a legitimate
portability error to someone who has debugged his code in a
an implementation where :ADJUSTABLE NIL arrays might still be
adjustable and then tried ported his code to an implementation
which is more conservative in its interpretation.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY):
Define that omitting the :ADJUSTABLE option to MAKE-ARRAY or
explicitly supplying :ADJUSTABLE NIL may not guarantee a
non-adjustable array.
Define that ADJUSTABLE-ARRAY-P -must- be true of an array created
using :ADJUSTABLE T.
Define that ADJUSTABLE-ARRAY-P -might- be true of an array created
with no :ADJUSTABLE option or with :ADJUSTABLE NIL, but that it
-might- return false.
Clarify that the implication of the above is that saying that an
array A "is adjustable" means that (ADJUSTABLE-ARRAY-P A) => true.
Further clarify that the adjustability of an array has no necessary
relation to any value was given (or not given) as the :ADJUSTABLE
option in the call to MAKE-ARRAY which created the array A.
Clarify that there is no portable way to create a non-adjustable
array (that is, an array for which ADJUSTABLE-ARRAY-P is
guaranteed to return false).
Change the description of ADJUST-ARRAY to say that if an attempt
is made to adjust an array which is not adjustable (that is, an
array for which ADJUSTABLE-ARRAY-P would return false), an error
will be signalled.
Clarify that this legitimizes ADJUSTABLE-ARRAY-P as an appropriate
predicate to determine whether ADJUST-ARRAY will reliably succeed.
Rationale:
This effectively makes the status quo explicit.
While changing this to a tighter interpretation would be desirable, some
implementations have suggested that such a change might be very expensive
or impossible given their existing data storage layouts.
Although technically the changes to ADJUST-ARRAY are incompatible changes
from the spec, it's not believed that there are any implementations which
deviate, so we're still categorizing this as a clarification.
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and is compatible with this proposal.
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
in all cases, and are compatible with this proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic.
Discussion:
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
∂12-Jan-89 0117 X3J13-mailer Issue: APPEND-ATOM (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 01:16:56 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 01:15:28 PST
Date: 12 Jan 89 01:09 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: APPEND-ATOM (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-011528-11925@Xerox>
!
Issue: APPEND-ATOM
References: APPEND (p268)
Issue APPEND-DOTTED
Category: CHANGE/CLARIFICATION
Edit history: Version 1 06-Dec-88 by Steele
Problem Description:
The issue APPEND-DOTTED, as passed by X3J13, contains a minor technical
flaw: it can be construed as leaving undefined the case where an argument
to APPEND other than the last is an atom. The relevant paragraph of that
issue proposal is:
In the degenerate case where there is no last cons (i.e., the argument is
NIL) in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument
is a non-list, the result of APPEND or NCONC can be a non-list.
Here is the nit: the use of "i.e." leads one to believe that the
only degenerate case defined is that where the argument is NIL.
I suspect that "e.g." was intended, so as to make all atomic objects
ignored in other than the last argument.
Proposal (APPEND-ATOM:IGNORE):
In the degenerate case where there is no last cons (i.e., the argument
is an atom) in any but the last list argument, clarify that the entire
argument is effectively ignored. Point out that in this situation, if
the last argument is a non-list, the result of APPEND or NCONC can be
a non-list.
Proposal (APPEND-ATOM:ERROR)
In the degenerate case where there is no last cons (i.e., the argument
is an atom) in any but the last list argument, clarify that a value of
NIL is treated as an empty list and therefore effectively ignored, and
any other atom is an error. Point out that in this situation, if the
last argument is a non-list, the result of APPEND or NCONC can be a
non-list.
Examples:
Under APPEND-ATOM:IGNORE:
(APPEND '(a b) 'MOOSE '(c . d)) => (a b c . d) ;Proposed
(NCONC '(a b) 'MOUSSE '(c . d)) => (a b c . d) ;Proposed
(APPEND 'GUACAMOLE 17) => 17 ;Proposed
(NCONC 'SAUERKRAUT 17) => 17 ;Proposed
Under APPEND-ATOM:ERROR these cases would all be errors.
Rationale:
APPEND-ATOM:IGNORE makes a boundary case (a "zero-length dotted list")
consistent with other cases handled by the proposal APPEND-DOTTED:REPLACE.
APPEND-ATOM:ERROR would at least resolve a possible ambiguity.
Current Practice:
Lucid Lisp, KCL, and Symbolics Common Lisp all signal an error in both
interpreted and compiled code.
Cost to implementors:
Technically, the change for APPEND-ATOM:IGNORE should be relatively
small for those implementations which don't already implement it.
However, implementations which have microcoded APPEND or NCONC
incompatibly may find the small change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect only
NIL when SAFETY is 0. In this case, depending on implementation details,
requiring an ATOM check rather than a NULL check may slow things down.
Cost to users:
Each proposal is upward compatible.
Benefits:
Since dotted lists are allowed as a non-last argument, readers will
probably assume that the boundary case of a zero-length dotted list
(that is, an atom) also works, something that doesn't appear to be
guaranteed by a strict reading. Proposal APPEND-ATOM:IGNORE would
happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the language
will depend largely on how they view the relation between lists and dotted
lists. Those who view dotted lists as a special kind of list may feel
differently than those who view lists as a special kind of dotted list.
The downside of APPEND-ATOM:IGNORE is that APPEND is supposed to
operate on lists, and it is mildly offensive to let it accept atoms,
and worse yet to ignore them. Furthermore, a certain amount of useful
error checking may be lost.
Discussion:
Guy Steele supports proposal APPEND-ATOM:IGNORE, but with some qualms.
He raises it mainly because of the possibility that
APPEND-DOTTED:REPLACE was not worded exactly as intended.
∂12-Jan-89 0121 X3J13-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 01:21:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 01:20:02 PST
Date: 12 Jan 89 01:19 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-012002-11939@Xerox>
There has been discussion on this issue not reflected in the
writeup. Some of the cost/benefit analysis misses some of the
Costs to Users, for example.
!
Status: DRAFT
Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA
Forum: Cleanup
References: Back quote (pp349-351)
Category: CLARIFICATION/CHANGE
Edit history: 22-Dec-88, Version 1 by Pitman
Problem Description:
The consistent description of backquote has been disrupted by
recent changes in the semantics of APPEND.
The description at the bottom of p350 suggests that
`(foo ,@bar) can be legitimately interpreted as any of
#1: (list* 'foo bar)
#2: (append (list 'foo) bar)
#3: (append (list 'foo) bar '())
Unfortunately, issue APPEND-DOTTED has disrupted the equivalences
here because if BAR holds a dotted list, #1 and #2 are the same (they
preserve the `dotted cdr'), but #3 is different (it replaces the
`dotted cdr' with NIL). Under CLtL, a dotted list given to APPEND was
an error, so this case did not come up. But since ANSI CL will not make
this an error, this ambiguity must be resolved.
Proposal (BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:DIVERGENT):
Define that `(x1 ... xM . ,xN) is equivalent to (LIST* x1 ... xN).
The actual (EQL) object xN will be used without copying in the result.
The result itself might not be a proper list (e.g., if xN is an
atom or dotted list).
Define that `(x1 ... xM ,@xN) is equivalent to
(APPEND (LIST 'x1) ... (list 'xM) xN '()).
Any top-level list structure of the object xN will be copied in the
result, replacing (CDR (LAST xN)) with NIL (or replacing xN itself
with NIL if xN is an atom and issue APPEND-ATOM passes).
Proposal (BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:INTERCHANGEABLE):
Define that `(x1 ... xM . ,xN) is equivalent to (LIST* x1 ... xN).
The actual (EQL) object xN will be used without copying in the result.
The result itself might not be a proper list (e.g., if xN is an
atom or dotted list).
Define that `(x1 ... xM ,@xN) is equivalent to
(APPEND (LIST 'x1) ... (list 'xM) xN).
The actual (EQL) object xN will be used without copying in the result.
The result itself might not be a proper list (e.g., if xN is an
atom or dotted list).
Notes:
Note well that this has implications which go beyond dotted lists.
Currently, `(FOO ,@X) may be implemented by either
(LIST* 'FOO X)
or (APPEND (LIST 'FOO) X '())
or (APPEND (LIST 'FOO) X)
A consequence of the proposals above is to distinguish between
the two APPEND cases, forcing changes in the side-effect behavior
of backquoted structures currently exhibited by some implementations.
Test Cases:
;; Issue #1: Non-side-effect treatment of dotted lists.
(LET ((DOTTED (LIST* 'A 'B 'C)))
(VALUES `(FOO ,@DOTTED)
`(FOO . ,DOTTED)))
=> (FOO A B), (FOO A B . C) ;under proposal DIVERGENT
=> (FOO A B . C), (FOO A B . C) ;under proposal INTERCHANGEABLE
;; Issue #2a: Side-effects
;; Sometimes called the ``Standard Backquote Screw''
;; Structure is unintentionally shared.
(LET ((TAIL1 (LIST 'A 'B 'C))
(TAIL2 (LIST 'A 'B 'C)))
(FLET ((GET-XABC-COMMA-ATSIGN () `(X ,@TAIL1))
(GET-XABC-DOT-COMMA () `(X . ,TAIL2)))
(LET ((TEMP1 (GET-XABC-COMMA-ATSIGN))
(TEMP2 (GET-XABC-DOT-COMMA)))
(SETF (CADDR TEMP1) 'Z)
(SETF (CADDR TEMP2) 'Z)
(VALUES TEMP1 (GET-XABC-COMMA-ATSIGN)
TEMP2 (GET-XABC-DOT-COMMA)))))
=> (X A Z C), (X A B C), (X A Z C), (X A Z C) ;under proposal DIVERGENT
=> (X A Z C), (X A Z C), (X A Z C), (X A Z C) ;under proposal INTERCHANGEABLE
;; Issue #2b: Side-effects
;; Sometimes called ``Inverse Backquote Screw''
;; Structure is unintentionally copied.
(LET ((VAR 'X)
(VAL '7)
(THE-SETQ-TAIL (LIST NIL NIL)))
(LET ((COMMA-ATSIGN `(SETQ ,@THE-SETQ-TAIL))
(DOT-COMMA `(SETQ . ,THE-SETQ-TAIL)))
(SETF (CAR SETQ-TAIL) VAR)
(SETF (CADR SETQ-TAIL) VAL)
(VALUES COMMA-ATSIGN DOT-COMMA)
=> (SETQ NIL NIL), (SETQ X 7) ; under proposal DIVERGENT
=> (SETQ X 7), (SETQ X 7) ; under proposal INTERCHANGEABLE
Rationale:
This clarifies an ambiguity in the description of the language which was caused
by issue APPEND-DOTTED and APPEND-ATOM.
Although CLtL tries not to specify the sharing and side-effect implications
of backquote, there is no really principled reason for its failure to do so.
In practice, the failure to do so leads to gratuitous portability barriers.
Current Practice:
Currently, the definition of APPEND is such that it would be an error
to pass it a dotted list, so there is no possibility of discrepancy
because the interesting case is an "is an error" case.
Cost to Implementors:
Very small. Some implementations would need to change how they implement
backquote. Presumably this is a very isolated change.
Cost to Users:
Technically, none. Existing code is not supposed to rely on the distinctions
discussed here. The distinction will only be meaningful when ANSI CL goes into
effect.
In practice, since some implementations will have to change incompatibly,
some code which accidentally relies on the current behavior will break.
However, once such code is fixed, it will be more portable because
implementations will not gratuitously diverge.
Cost of Non-Adoption:
An ambiguity would exist in the language, confusing both users and
implementors.
Benefits:
An ambiguity would be removed.
Some gratuitous barriers to portability would be removed.
Aesthetics:
Proposal DIVERGENT makes things slightly harder to learn.
Both proposals make things more predictably portable, which presumably
has some aesthetic appeal.
Discussion:
Pitman thinks that either of these choices will be better than the status quo.
Given that some people already think of ., and ,@ as interchangeable and merely
a matter of personal style, it would be better to go with option INTERCHANGEABLE.
∂12-Jan-89 1413 X3J13-mailer Issue: CLOSE-CONSTRUCTED-STREAM (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 14:13:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 13:58:56 PST
Date: 12 Jan 89 13:58 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: CLOSE-CONSTRUCTED-STREAM (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-135856-13358@Xerox>
This Issue has too many Proposals. We've not had the
time to narrow them down.
!
Status: DRAFT
Forum: Cleanup
Issue: CLOSE-CONSTRUCTED-STREAM
References: Close (CLtL p. 332), WITH-OPEN-STREAM
(CLtL p 330), make-synonym-stream, make-broadcast-stream,
make-concatenated-stream, make-two-way-stream,
make-echo-stream, make-string-input-stream,
make-string-output-stream, with-input-from-string,
with-output-from-string
Related issues: CLOSED-STREAM-OPERATIONS
Category: Clarification/Change
Edit history: Masinter, 6-Jan-89, Version 1
Masinter, 12-Jan-89, Version 2
Problem description:
First some terminology:
A "composite" stream is one created with MAKE-SYNONYM-STREAM,
MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-TWO-WAY-STREAM,
MAKE-ECHO-STREAM.
The "constituents" of a composite stream are the streams it points to:
the SYMBOL-VALUE of the symbol given to MAKE-SYNONYM-STREAM
the streams given to MAKE-BROADCAST-STREAM or MAKE-CONCATENATED-STREAM
the input-stream and output-stream given to MAKE-TWO-WAY-STREAM or MAKE-ECHO-STREAM.
A "constructed" stream is either a composite stream or one created with
MAKE-STRING-INPUT-STREAM, MAKE-STRING-OUTPUT-STREAM, WITH-INPUT-FROM-STRING,
WITH-OUTPUT-FROM-STRING.
The function "CLOSE" is currently described in 21.3, which starts "This
section contains discussion of only those operations that are common to all
streams." This would seem to imply that they apply to constructed streams.
The definition of CLOSE "The argument must be a stream. No further input/output
operations may be performed on it. ... " It further states "... and it is
permissible to close an already closed stream."
However, the behavior on the constructed streams is not well defined, and
implementations (apparently) differ.
Proposal (CLOSE-CONSTRUCTED-STREAM:IS-ERROR):
It "is an error" to call CLOSE on a constructed stream. CLOSE might signal an
error, or the result of CLOSE could cause the constituent streams to be closed,
etc, but the effect is implementation-dependent.
Proposal: (CLOSE-CONSTRUCTED-STREAM:SIGNALS-ERROR)
Calling CLOSE on a constructed stream signals an error.
Proposal (CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY):
The effect of CLOSE on a constructed stream is to close the "argument" stream
only. No i/o operations are permitted after the call to CLOSE on the stream
given to CLOSE; There is no effect on the constituents of composite streams.
For streams created with MAKE-STRING-OUTPUT-STREAM, the result of
GET-OUTPUT-STREAM-STRING is unspecified after CLOS. For composite streams,
the call to CLOSE has no effect on any of the constituent streams.
The "links" to the constituents may be broken; if the proposal in STREAM-ACCESS
passes, the results of the accessor functions there are unspecified after the
call to CLOSE.)
Proposal: (CLOSE-CONSTRUCTED-STREAM:CLOSE-CONSTITUENTS)
CLOSE first closes its argument; it then operates recursively on the constituents
of composite streams.
Examples:
>>not written; sorry<<
Rationale:
Specifying seems better than not saying what happens, even if it is
"implementation-dependent".
Current practice:
Implementations seem to vary widely.
Cost to Implementors:
Varying, depending on the current level of conformance. Making the changes
themselves is probably trivial (to the "close" method for each kind of
constructed stream type) but it is possible that system code might depend
on the behavior.
Cost to Users:
Likely small; we've not found any good uses for CLOSE on composite streams.
Cost of non-adoption:
Continued minor ambiguity
Performance impact:
near zero
Benefits:
The language would be more well specified.
Esthetics:
Well-specified languages are usually easier to deal with.
Discussion:
Signalling an error is reasonable if no Common Lisp program ever needs to
call CLOSE on a composite stream. We could not come up with a legitimate
case where you wouldn't instead close the underlying stream if that's what
you wanted.
Allowing the result to be implementation dependent is the "status quo".
ARGUMENT-STREAM-ONLY is probably the "safest" in that it makes it
harder to accidentally close a stream that wasn't intended. It
seems counterintuitive and yet it probably wouldn't be harmful
if it were well-defined that this was what it did.
CLOSE-CONSTITUENTS could be an incompatible change for some
implementations. It makes more sense for things like broadcast streams
(which are usually non-interactive) than it does for echo streams
(which are sometimes interactive).
∂12-Jan-89 1526 X3J13-mailer Issue: REMF-MULTIPLE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 15:24:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 15:11:46 PST
Date: 12 Jan 89 15:05 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: REMF-MULTIPLE (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-151146-1173@Xerox>
!
Status: DRAFT
Issue: REMF-MULTIPLE
References: REMPROP (p166), REMF (p167)
Category: CLARIFICATION/CHANGE
Edit history: 26-Jan-88, Version 1 by Pitman
12-Jan-89, Version 2 by Masinter (add IS-ERROR per Moon)
Problem Description:
The descriptions of REMF and REMPROP are not explicit about what happens in
the case that a duplicated indicator occurs on the plist. One or both indicators
might be removed.
Proposal (REMF-MULITPLE:REMOVE-ONE):
Clarify that REMF and REMPROP at most one indicator/value pair from the designated plist.
Rationale:
In a property list maintained by the normal property list operations, there will
only be one property by each name. This approach won't waste time trying to remove
other properties which are not present in the first place.
Proposal (REMF-MULTIPLE:REMOVE-ALL):
Clarify that REMF and REMPROP remove all matching indicator/value pairs from the
designated plist.
Rationale:
In a property list maintained by other operations than the standard ones,
this might be useful. Also, since the return value of REMF and REMPROP is
not well-defined, iterating to remove more than one property is expensive
because you have to start over from the head of the list.
Proposal (REMF-MULTIPLE:IS-AN-ERROR):
Clarify that it "is an error" to pass a list with a duplicated
indicator to REMF or any other function that takes a
property list (including GETF); it "is an error" for a
symbol to have duplicated properties on its property list.
Rationale:
The only thing that CLtL pp 163-167 says about
duplicated indicators on plists is that there aren't any
(first line on page 164). It does not even gurantee
that GETF returns the first occurrence.
Test Case:
;; Case #1 - removing symbol properties,etc. using REMPROP
(DEFUN REMF-MULTIPLE-TEST-1 ()
(LET ((SYMBOL (GENSYM)))
(SETF (SYMBOL-PLIST SYMBOL) (LIST 'A 'B 'C 'D 'A 'B 'C 'D))
(FORMAT T "~&Before: ~S~%" (SYMBOL-PLIST SYMBOL))
(REMPROP SYMBOL 'A)
(FORMAT T "~&After: ~S~%" (SYMBOL-PLIST SYMBOL))
(FORMAT T "~&This implementation uses REMF-MULTIPLE:~:[REMOVE-ALL~;REMOVE-ONE~] ~
for REMPROP.~%"
(GET SYMBOL 'A))))
;; Case #2 - removing keywords,etc. using REMF
(DEFUN REMF-MULTIPLE-TEST-2 ()
(LABELS ((HELPER (&REST ARGUMENTS &KEY (A 1) (B 2))
(FORMAT T "~&Helper received: ~S~%" ARGUMENTS)
(LIST A B))
(DRIVER (&REST ARGUMENTS)
(FORMAT T "~&Helper received: ~S~%" ARGUMENTS)
(SETQ ARGUMENTS (COPY-LIST ARGUMENTS))
(REMF ARGUMENTS ':A)
(APPLY #'HELPER ARGUMENTS)))
(LET ((RESULT (DRIVER :A 3 :B 4 :A 5 :B 6)))
(FORMAT T "~&Returned: ~S~%" RESULT)
(FORMAT T "~&This implementation uses REMF-MULTIPLE:~:[REMOVE-ALL~;REMOVE-ONE~] ~
for REMF.~%"
(= (CAR RESULT) 5)))))
Current Practice:
Symbolics implements REMF-MULTIPLE:REMOVE-ONE.
Cost to Implementors:
For implementations needing to change, the cost of a change is probably very
small in most cases. Implementations needing change which do REMPROP and/or REMF
in microcode might have a slightly harder time, but any change should still be
very localized.
Cost to Users:
None. Users must tread lightly on this issue right now because it is not well-defined.
Cost of Non-Adoption:
The language description would continue to be vague for no particularly good reason.
Benefits:
IS-ERROR at least makes the situation more explicit. For the other proposals,
users who want to use REMPROP or REMF in situations which involve lists that might
have duplicated elements would be able to do so more reliably.
Aesthetics:
There is probably no particular aesthetic reason to think one of these solutions
is better than the other, but having the issue nailed down is probably an aesthetic
improvement.
Discussion:
This issue, first brought up in Cleanup almost a year ago, got lost.
Pitman is agnostic on this for now. There are advantages to both.
If everybody already implements REMOVE-ONE, that would seem the way to go.
"If we're going to extend Common Lisp to allow duplicated indicators on
plists, we should do it for all the property list functions, not
just REMF and REMPROP."
∂12-Jan-89 1642 X3J13-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 16:42:06 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 16:27:25 PST
Date: 12 Jan 89 16:26 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-162725-1374@Xerox>
This issue has a number of additional comments at the end.
!
Status: DRAFT
Forum: Cleanup
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
DELETE-IF-NOT, DELETE-DUPLICATES, NSUBSTITUTE,
NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT (pp254-256); NCONC,
NRECONC (p269); NBUTLAST (p271); NSUBST, NSUBST-IF,
NSUBST-IF-NOT (p274); NUNION, NINTERSECTION,
NSET-EXCLUSIVE-OR (pp276-279).
Category: CLARIFICATION/CHANGE
Edit history: 11-Feb-87, Version 1 by Dave Andre (DLA@Symbolics.COM)
29-Oct-87, Version 2 by Pitman (flesh out proposals)
28-Nov-88, Version 3 by Pitman (revised presentation)
29-Nov-88, Version 4 by Pitman (slight editing per DLA)
Problem Description:
Currently, the exact nature of the side-effect performed by list
modification routines is not specified.
Either the specific modifications allowed should be specified so that
programmers can rely on them and implementors can avoid accidentally
causing problems by introducing well-meaning optimizations, or else
the documentation should explicitly state that the effects are
unspecified so that programmers will not depend on them and
implementors will feel comfortable about doing interesting optimizations.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE):
Clarify that the way in which the destructive behavior of the
operators below is achieved is explicitly vague in a number of ways,
in order to provide individual implementations the necessary
flexibility to do useful optimizations.
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-IF-NOT test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (NOT (FUNCALL test ITEM)))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
(NSUBSTITUTE-IF-NOT new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists (except the last, which is not required to
be a list and must not be modified).
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NBUTLAST list ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given list.
(NSUBST new-object old-object tree)
(NSUBST-IF new-object test tree)
(NSUBST-IF-NOT new-object test tree)
is permitted to SETF any part of the TREE of conses which must
be replaced by NEW-OBJECT.
Note, however, that since the tree might be a degenerate tree
containing no conses and since the side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
Note: The above clarifications are not intended as complete functional
descriptions. They are intended to augment (rather than to replace)
other descriptions already in effect.
Test Cases:
For GETF...
(SETQ FOO (LIST 'A 'B 'C 'D 'E 'F)) ==> (A B C D E F)
(SETQ BAR (CDDR FOO)) ==> (C D E F)
(REMF FOO 'C)
BAR ==> ??
In Symbolics Common Lisp, BAR holds (C D E F).
CLtL allows other interpretations. eg, BAR might hold
(C), (NIL), (C NIL) or (C D).
Under this proposal, any of these interpretations (and others as well)
would still be valid
For DELETE...
(SETQ FOO (LIST 'A 'B 'C)) ==> (A B C)
(SETQ BAR (CDR FOO)) ==> (B C)
(SETQ FOO (DELETE 'B FOO)) ==> (A C)
BAR ==> ??
(EQ (CDR FOO) (CAR BAR)) ==> ??
In Symbolics Common Lisp, these last two expressions return ((C)) and T.
Under this proposal, either of these interpretations (and others
as well) would be valid.
Rationale:
Implementations already vary widely on their implementation techniques
for these functions. This effectively clarifies the status quo, making
it more clear to programmers what they may rely upon in portable code.
Current Practice:
All valid implementations are believed to comply.
Cost to Implementors:
None. This is the status quo for implementors.
Cost to Users:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are already in such danger, and this change to the documentation would
just publicize it. The clarification would -encourage- good programming
practice by warning people to only obey the published contract of the
above-mentioned functions.
There is, however, no automatic technique for making this check for
programs already in error. Bugs due to unexpected side-effects are in
general among the hardest to reckon with.
Cost of Non-Adoption:
Programmers may naively believe there is only one possible or reasonable
implementation of these functions. Some implementors may shy away from
reasonable optimizations out of a paranoid belief that deviating from
some vague, unspoken rules will lead to programmer unrest. Making these
things explicitly vague clarifies the implementor's rights in a way that
permits numerous useful optimizations.
Benefits:
Users would be discouraged from taking advantage of subtle details
of these destructive operations because such details would be explicitly
not guaranteed to be portable.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion. For example, in Symbolics systems,
DELETE of a cdr-coded list could use the implementation primitive
%CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
pointers.
Garbage collection effectiveness can also be improved. For example,
all of the destructive operations which remove objects (eg, REMF)
could remove CAR pointers to removed objects which are more volatile
than the list itself, assisting the garbage collector and thereby
improving memory usage and paging performance.
Non-Benefits:
Users who inadvertently depend on side-effect behavior may be rudely
surprised when moving between implementations.
Compatibility with older Lisp dialects is diminished.
Performance Impact:
Metering in Symbolics test systems have shown that there are substantial
performance gains to be had by allowing implementations flexibility in
these areas.
Aesthetics:
Most of these functions implement abstract operations. For example,
REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
Discussion:
Andre's original version of this proposal pushed for explicitly vague
descriptions of these functions' side-effect behavior. He believes
that if users want more predictability from these functions, they
should write private variants that implement whatever predictability
they require.
Pitman originally opposed this position because he weighed portability
a higher concern. Since the original discussion, however, his views on
how to resolve this priority have been refined, and he now believes
that leaving things vague is appropriate. As such, he now supports what
is effectively Andre's original proposal.
Pitman and Andre support this proposal.
!
Additional Comments:
"...I'd like to see a section in the spec that concerns these
"destructive" operations to say explicity that it is perfectly
all right for them _not_ to destroy anything but instead to
"cons" new results. ...
Change "the destructive behavior of the operators" to say
"if any".
Change the proposal by...
- striking the three or so places that it explicitly reminds you
to use SETQ in case a side-effect doesn't occur
- adding some general purpose verbiage that says something like
that the purpose of these operators is to provide you the most
efficient algorithm, and that in some situations or some
implementations, there may be some reasons why the most
efficient thing is to copy rather than to side-effect. As such
none of these operators are actually required to side-effect,
but the user should assume that, whatever the implementation, it
will have speed competitive with or surpassing a side-effecting
implementation.
SORT, STABLE-SORT, and MERGE are conspicuously
absent from the list. They should be added in as well.
Should NCONC and NBUTLAST be explicitly vague?
Whereas it seems less
useful to maintain the actual list substructure in (SETF (GETF ...) ...),
DELETE, NREVERSE, NSUBSTITUTE, etc, I can see a very useful role for the
specific semantics of these few -- that they change the cdr of a particular
cons cell -- and would question very highly the value of striving for speed
at the cost of correct semantics.
NSUBLIS seems to be missing; but I would classify it in with NSUBST,
NCONC and NBUTLAST of the previous paragraph.
- - - - -
SETF of GETF, REMF should be specified.
NCONC, NBUTLAST, NSUBLIS, NSUBST, NSUBST-IF, NSUBST-IF-NOT
should be specified.
Since the argument for explicitly-defined is portability and the utility of
reliable definitions, and the argument for explicitly-vague is performance,
we should leave things explicitly vague only where
a) it matters for performance and
b) reasonable programs would not rely on the
"defined" behavior
I believe the things I say should be explicitly-vague are the ones where
good style would avoid depending on side-effect behavior and where
performance matters, while the ones I say should be explicitly-defined,
there are reasonable applications which might rely on the explicit
definition, and no strong claims that "explicitly-vague" can make a
difference in performance.
- - - - - - - - -
The NSUBSTITUTE functions seem so "obvious" in implementation that it
seems hard to justify not explicitly specifying them. Seems to me
thatclassifying the sequence functions as a group is not of any
significance. There really are only three basic sequence functions
listed there and they are all quite different, and for different
reasons: NREVERSE wants to be explicitly-vague primarily because of the
list reversal, and for that primarily because of optimizations needed
for cdr-coded implementations; DELETE because of
cdr-deleted-element-off-front-of-list for lists and
we've-got-to-copy-the-non-adjustable-array for vectors; NSUBSTITUTE I
can only imagine so that an implementation could "cheat" and use
SUBSTITUTE, or just because it is a destructive sequence function.
- - - - - - - - - - -
Where you say
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
you also need to say that it is an error after this operation to
reference any CONS that was formerly part of the top-level list
structure and is no longer part of it. Of course this applies not
just to REMF, but also to SETF of GETF, NREVERSE, DELETE,
DELETE-DUPLICATES, NCONC, NUNION, NINTERSECTION, NSET-EXCLUSIVE-OR,
SORT, STABLE-SORT, and MERGE and to the ones that are defined to be
equivalent to these; these are all the ones that might change
list structure rather than just replacing CAR elements.
You see, not only are these destructive functions allowed to change
the components of the conses that make up the top-level list structure
of the argument, they are also allowed to reuse the storage of those
conses for something else that isn't a cons at all. You may recall
that this was DLA's original motivation for bringing up the issue.
I strongly disagree with Larry's contention that SETF of GETF, REMF,
SETF of GET, and REMPROP are not reasonable to include in this proposal.
If anything, the property list operators have less justification for the
user to depend on the representation than (for example) DELETE, not more
justification.
I disagree with JonL's and Larry's contention that NBUTLAST is not
reasonable to include in this proposal. I think it would be reasonable
to implement NBUTLAST by sliding all the list elements to the right n
positions and then returning NTHCDR n of the original list. However,
CLtL p.271 could be interpreted as -requiring- NBUTLAST to be
implemented in terms of RPLACD of a specific cons, rather than just
mentioning that as an example; if so, I would change my mind and
agree that NBUTLAST should be excluded from this proposal.
I also believe that NCONC (and hence by implication NRECONC) is
reasonable to optimize, but on that point I could easily be swayed to
change my mind since I can't think of any really plausible
optimizations. However, CLtL doesn't offer much evidence that a
specific implementation of NCONC is required.
For the others Larry listed (NSUBST, NSUBST-IF, and NSUBST-IF-NOT), what
the proposal actually says ("is permitted to SETF any part of the TREE
of conses which must be replaced by NEW-OBJECT.") is not proposing to
allow an implementation to modify any portion of a cons other than what
CLtL requires it to modify. Perhaps that means there is no reason to
include these in the proposal because the proposal says exactly the same
thing about these that CLtL says. BTW CLtL appears to -require- a
side-effect for these rather than merely -allowing- a side-effect.
∂12-Jan-89 1711 X3J13-mailer Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 17:11:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 17:04:55 PST
Date: 12 Jan 89 17:04 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-170455-1498@Xerox>
This issue is a generalization of PATHNAME-TYPE-UNSPECIFIC,
which it subsumes.
!
Forum: Cleanup
Issue: PATHNAME-UNSPECIFIC-COMPONENT
Forum: Cleanup
References: File System Interface (pp409-427)
Category: CHANGE
Edit history: 27-Dec-88, Version 1 by Pitman
Subsumes: Issue PATHNAME-TYPE-UNSPECIFIC
Problem Description:
In some file systems, it is inappropriate to represent particular
pathname components, either all the time or in some specialized
circumstance.
- Unix pathnames never have a version field.
- In some file systems, specifying a device and a directory means
something very different than specifying the device alone,
particularly when the device is a "logical device" that may
already imply a directory.
- Some Unix pathnames have types and others do not. For example,
it is possible to make files named "foo." and "foo" which are
distinct. CLtL (p412) specifies that the type is ``always a
string, NIL, or :WILD.'' This description is too restrictive
to be practical in this case. One of these (usually the former)
can get a type of "" but it is not clear how to represent the
other. If NIL is used, merging primitives cannot detect that the
field is filled and should not be merged against.
- ITS pathnames have either a version or a type, but never both.
"JOE;FILE 32" has a directory, a name, and a version.
"JOE;FILE TEXT" has a directory, a name, and a type.
"JOE;FILE TEXT 32" is not a possible ITS filename.
Proposal (PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN):
Permit :UNSPECIFIC as a value of the DEVICE, DIRECTORY, TYPE, or
VERSION field of a pathname for file systems in which it makes sense.
When a pathname is converted to a namestring, NIL and :UNSPECIFIC
are treated as if the field were empty. That is, they both cause the
component not to appear in the string.
When merging, however, only a NIL value for a component will be
replaced with the default for that component, while :UNSPECIFIC
will be left alone as if the field were filled.
Portable programs should expect to find :UNSPECIFIC in the device,
directory, type, or version field in some implementations.
Portable programs should not explicitly place :UNSPECIFIC in any
field, since that it might not be permitted in some situations,
but portable programs may sometimes do so implicitly.
Test Case:
;; #1: Non-portable code. This may signal an error in some
;; implementations where an unspecific type makes no sense.
(MAKE-PATHNAME :TYPE :UNSPECIFIC) ;not portable
;; #2: In this example, assume a Unix file system.
(PATHNAME-TYPE (PARSE-NAMESTRING "foo."))
=> ""
(PATHNAME-TYPE (PARSE-NAMESTRING "foo"))
=> :UNSPECIFIC
(PATHNAME-TYPE (MERGE-PATHNAMES (PARSE-NAMESTRING "foo")
(MAKE-PATHNAME :TYPE "BAR")))
=> :UNSPECIFIC
;; #3: In this example, assume an ITS file system.
(LET ((P (PARSE-NAMESTRING "FOO 32")))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> (:UNSPECIFIC 32)
(LET ((P (PARSE-NAMESTRING "FOO TEXT")))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> ("TEXT" :UNSPECIFIC)
(LET ((P (MERGE-PATHNAMES (PARSE-NAMESTRING "FOO 32")
(PARSE-NAMESTRING "FOO TEXT"))))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> (:UNSPECIFIC 32)
;; Note: It is not the intent of this proposal to actually legislate
;; the canonical representation of Unix pathnames "foo." and "foo",
;; nor of ITS pathnames "FOO 32" and "FOO TEXT". That should probably
;; be done, but under separate cover. The above examples are intended
;; only to demonstrate how this proposal will permit the representation
;; of pathnames not usefully representable under CLtL.
Rationale:
This is, by necessity, current practice in some implementations
already.
Current Practice:
Symbolics Genera uses a file types and versions of :UNSPECIFIC on
Unix and ITS file systems, for example.
Cost to Implementors:
None. No change to any implementation is forced.
Some implementations which already do this are legitimized.
Some implementations which use a non-standard token other than
:UNSPECIFIC to implement this functionality would want to switch
to use :UNSPECIFIC so that portable programs could expect it.
Cost to Users:
Some programs which manipulate pathnames should be updated to expect
:UNSPECIFIC in the type fields in some situations.
Any program which doesn't already expect :UNSPECIFIC is already not really
portable, however, given that some implementations have been forced to
go beyond the standard in order to represent all possible pathnames.
Cost of Non-Adoption:
Some implementations would be unable to both represent all possible
pathnames in a rational way and at the same time to conform to the
standard. Such an inability would seriously jeopardize the usefulness
of Common Lisp in the design of serious programs.
Benefits:
Some programs involving pathnames would be more portable.
Aesthetics:
Sweeping a hairy situation under the rug doesn't make it go away.
This change makes things appear less simple, but since in reality
they were less simple, it is effectively a simplification of the
correspondence between the CL model and reality.
Discussion:
Pitman and Moon support PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.
This feature existed (for types) in the Colander draft edition of
CLtL, but was removed for the Laser edition. The following text is
excerpted from the Colander edition, p259:
``??? Query: Is :unspecific really needed over and above nil?
``A component of a pathname can also be the keyword
:UNSPECIFIC. This means that the component has been explicitly
determined not to be there, as opposed to be missing. One way
this can occur is with generic pathnames, which refer not to
a file but to a whole family of files. The version, and usually
the type, of a generic pathname are :unspecific. Another way
:unspecific is used to represent components that are not simply
supported by a file system. When a pathname is converted to a
namestring, nil and :unspecific both cause the component not to
appear in the string. When merging, however, a nil value for
a component will be replaced with the default for that
component, while :unspecific will be left alone.''
"The stuff about generic pathnames in the discussion section
was brain damage and may have lead to the confusion that caused
:unspecific to be dropped from Common Lisp. Only the stuff about
components not supported by a file system makes sense."
∂12-Jan-89 1731 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 17:31:09 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 17:20:59 PST
Date: 12 Jan 89 17:20 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-172059-1554@Xerox>
!
Issue: PACKAGE-FUNCTION-CONSISTENCY
References: 11.7 Package System Functions and Variables (pp182-188)
Category: CLARIFICATION/CHANGE
Edit history: 21-Oct-88, Version 1 by Pitman
12-Jan-89, Version 2 by Masinter (add MORE-PERMISSIVE option)
Problem Description:
CLtL is vague about whether either or both of package or package name
are permissible in some cases.
Proposal (PACKAGE-FUNCTION-CONSISTENCY:PERMISSIVE):
Clarify that it is permissible to pass either a package object
or a package name (symbol or string) in the following situations:
- the :USE argument to MAKE-PACKAGE or IN-PACKAGE
- the first argument to IN-PACKAGE, FIND-PACKAGE, and RENAME-PACKAGE
- the second argument to INTERN, FIND-SYMBOL, UNINTERN
- the second argument to EXPORT, UNEXPORT, IMPORT,
SHADOWING-IMPORT, and SHADOW
- the first argument (or a member of the list which is the first
argument) to USE-PACKAGE or UNUSE-PACKAGE.
- the PACKAGE argument to DO-SYMBOLS.
- the PACKAGE argument to DO-EXTERNAL-SYMBOLS.
- the PACKAGE argument to DO-ALL-SYMBOLS.
If FIND-PACKAGE is given a package object as an argument, it simply
returns it.
If IN-PACKAGE is given a package object as an argument, that package
is selected. It is an error if, when a package object is given as a
first argument to IN-PACKAGE, a :USE list is explicitly specified and
does not exactly match the package or :NICKNAMES is explicitly supplied
and does not exactly match the package.
Clarify that the functions PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST are (at least conceptually)
accessors to package data structures and permit only package objects
as arguments.
Clarify that the function MAKE-PACKAGE permits only a package name
as an argument since it does not make sense to create an existing
package.
Clarify that package nicknames must always be expressed as package
names (symbols or strings) and may never be actual package objects.
Proposal: (PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE)
In addition, require that PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST to accept names,
too.
Examples:
(INTERN "FOO" "KEYWORD") => :FOO
(DEFVAR *FOO-PACKAGE* (MAKE-PACKAGE "FOO"))
(RENAME-PACKAGE "FOO" "FOO0")
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO0"
Under MORE-PERMISSIVE,
(PACKAGE-NAME "SYS") might return "SYSTEM".
Rationale:
This makes things more consistent.
MORE-PERMISSIVE adds a generally useful capability.
Current Practice:
Symbolics Genera & Lucid permits strings as package names.
Symbolics Cloe does not permit strings as package names.
In Lucid FIND-PACKAGE and IN-PACKAGE require names.
Cost to Implementors:
Small. A tiny bit more for MORE-PERMISSIVE.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Implementations would continue to vary gratuitously, leaving a potential
for portability problems.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This makes things more regular, and so presumably more aesthetic.
Discussion:
Pitman ran across this problem while trying to port Macsyma to various
implementations. Discussion with other maintainers of portable programs
shows this is a common source of aggravation in portable code.
Since the pathname accessors all take namestrings or streams, one might
easily argue that it would be more consistent for PACKAGE-NAME,
PACKAGE-NICKNAMES, etc. to also take arguments of package names. After
all,
(PACKAGE-NAME "FOO") => "FOO"
is no stranger than
(NAMESTRING "JOE:fred.lisp") => "JOE:fred.lisp".
It would be possible to say that MAKE-PACKAGE took package objects as
arguments and just returned that package. That might have limited
usefulness on rare occassions, but mostly seemed too far out in left
field to bother suggesting it.